This post does NOT cover the use of the Twilio library, because we simply haven’t had the need for it for this project. The next steps explain how to receive, and reply to SMS messages that are sent to a Twilio number, with Twilio set to make requests to a CakePHP app.

This example is intended for CakePHP 2.1, because it makes this process so easy, but a few tweaks will make it work with earlier versions.

1. Setup a Twilio number, and a TwiML application.
If you got to this point in the post, your should know what Twilio is. You can use the number that comes with the trial version, but we decided to purchase a number that we’ll keep around to test this project, and future ones.

After you purchase the number, you’ll be taken to a page where you can enter the Request URLs that Twilio will call when it receives Voice call and SMS messages. You could enter Request URLs directly here, but don’t worry about those for now, we will create a TwiML application instead. One reason why we prefer using a TwiML application is because it makes it easier to switch quickly between development urls and production urls.

While in your account, open the ‘Apps’ tab, and create a new TwiML app. You should see a field for the name, and sections for the Voice, and below, the SMS parameters. Name the app something funky, and in the SMS section, look for the field where you can enter the Request URL that Twilio will call. Our Request URL looks something like this: http://fancydomain.com/twilio/installations/receive_sms.xml

Here are the different parts, and how they relate to our CakePHP project:

• fancydomain.com – just the domain, nothing special here.
• twilio – this is optional, but we use the twilio prefix to make our code more readable.
• installations – this is our controller, yours will probably be different.
• receive_sms – this is our action that receives an SMS message, and sends a response.
• xml – last but not least, the file extension that controls the view to output the xml response.

The next few steps will cover the changes (or additions) you need to make to your CakePHP app so that each parts of the Request URL is treated correctly.

2. Setting up the Twilio prefix
This part is optional. If you remove ‘/twilio’ from the URL, you can skip this step. If you decide to not use this, just remember not to include the ‘twilio_’ prefix in your action name when you get to step 4.

All that is required is one line in your ‘app/Config/core.php’ file. Find the line that configures ‘Routing.prefixes’, and change it to the following to setup the ‘twilio’ prefix. We already had the ‘admin’ prefix so ours looks like this:

Configure::write('Routing.prefixes', array('admin', 'twilio'));

3. Parsing the file extension in the router
Another easy step, we need a single line in ‘app/Config/routes.php’ to handle the ‘.xml’ extension of our Request URL. Adding the following line — we added it at the beginning — will tell CakePHP to switch to the XmlView to render the response as XML.

Router::parseExtensions('xml');

4. Add the action
In our Request URL we specified, first, the ‘twilio’ prefix, then the ‘installations’ controller, and finally the ‘receive_sms’ action, so we need to create the following function in ‘app/Controller/InstallationsController.php’:

public function twilio_receive_sms() {
  //make sure we have a post request
  if (!$this->request->is('post')) {
    throw new MethodNotAllowedException();
  }

  //find the correct installation using the twilio phone number
  $installation = $this->Installation->findByPhone($this->request->data['To']);
  if ($installation == null) {
    return;
  }

  $message = array(
    'installation_id' => $installation['Installation']['id'],
    'source' => $this->request->data['From'],
    'message'=> $this->request->data['Body'],
  );

  $this->Installation->Message->create();
  if (!$this->Installation->Message->save($message)) {
    return;
  }

  //send response
  $this->set('response', array(
    'Response' => array(
      'Sms' => 'Thank you!',
    )
  ));
  $this->set('_serialize', 'response');
}

A few notes about this code before we move on. At the top, we check to make sure the action is called from a POST request. If you specified GET instead of POST in your TwiML application, then you should check for the same method your assigned to your Request URL. Then, for our project, each installation object is matched with a Twilio number, so we find the installation with the ‘findByPhone’ method, passing it the ‘To’ field that Twilio passed to the Request URL. We then create a message array, but in this case, we only need the ‘From’ and ‘Body’ fields. If you want to know what data Twilio passes, you should read the Twilio SMS Request page in their documentation. After that, we create and save a message object linked to the correct installation. Finally we create an array for the response object, and make sure we set the ‘_serialize’ variable so that the XmlView will know to output the content of the ‘response’ variable as XML, following the instructions for the JSON and XML views of CakePHP.

5. Try it!
Give it a go. Send a text message to your Twilio number, and if you set up everything correctly, you should receive an SMS reply that says ‘Thank you!’.

We’re kicking this series off with something very inexpensive. The item I’m writing about today is post-it glue, available from Staples for $2.04. I mean, obviously post-its are useful, everyone knows that. But not many people know that you can actually buy glue sticks that will let you turn anything into a post-it. Seriously, try it. It’s a little bit scary how satisfying it is to postitify all the arbitrary pieces of paper in your life. We found this stuff a little over a year ago, and have been using it since. Whenever we do any paper prototyping, it goes into heavy rotation.

The fun and challenge of sketching and prototyping is to craft something that’s at the proper resolution to teach you something. A prototype that looks too polished is liable to intimidate the person you’re asking to critique it; it looks too close to done, and suggestions for major changes would feel out of line. Anyway, too much detail too early is a waste of time, since you’re going to revise everything as you go. And yet, at least parts of your prototype need to be detailed enough to discern opportunities and problems, to imagine what it would be like in use. How much detail to include, and where to put it, depends a lot on what you’re trying to learn from the prototype. In my experience, you may need to include a convincing-looking animation in a prototype, even when everything else can look sketchy and wireframey, if (for example) you’re trying to figure out how a certain component can grab the user’s attention.

So the great thing about post-it glue is that it gives you unlimited ability to create removable and replaceable parts for your paper prototype while retaining just the look and feel you want. This helped us stretch the principles of paper prototyping to apply not just to conventional screen interfaces (though we do those, too), but to prototyping spatial and tangible interactions. If you’re testing, say, the playability of a scavenger-hunt type game, you can’t just sketch components onto a post-it and expect them to be legible from across the room… you want to print out something clear, clean and iconic and turn it into a post-it.

In the gallery below, you can see how we used post-it glue to fake a sequence of system actions and reactions scattered among many screens all around a room.

A while back we did this really fun project designing an exhibit about the International Space Station with some guys from gsmprjct, due to open at the Cosmodôme in Laval this last winter. We helped brainstorm the concept for the ISS portion of the exhibit, and then came up with some game mechanics and put together the interaction design to get a whole group of visitors to work together gathering components from all over the world to assemble the International Space Station. We also developed a deep and abiding love for cosmonauts and their moustaches.

So we ran across some promotional videos and some pictures of how the exhibit turned out. (The video’s in French, FYI.)

And there are some lovely pictures up on the Cosmodôme’s Facebook page. (#9 and #1 are the room we worked on.)

We’ll have some more photos of the final project to post here soon!

luciole is simplicity itself. It’s a kit for building adaptable, rechargeable lights. It’s a great first-time project for someone who wants to learn about electronics (or teach their kid). But we wanted to go above and beyond what most electronics kits offer you.

We’re putting a lot of thought into the design of the circuit boards for luciole, aiming to create something that you can assemble and reassemble into lots of different shapes. This gives you the freedom to create whatever form you want for your light, and to change that form if you change your mind.

Moreover, if you want something with a little more polish, we’ll be offering a few different kinds of cases designed specifically for luciole. Forget about finishing your assembly and ending up with a bare PCB, or stuffing it inside an altoids tin (which, OK, sometimes conveys a sense of DIY-chic, but you want other options, don’t you?). luciole gives you the sense of know-how and ownership that comes with hacking your own electronics, but if you’ve got it on display when your grandparents come over, they won’t think you’re a crazy bomb-maker. They’ll just think you have great taste.

You can assemble the components on these guys in various different ways — whatever suits your purpose. The center piece of the PCB where the LEDs attach can pop out of the board.

With LEDs separated from the base and batteries, you can use luciole to make yourself a focal desk lamp. Or you can make something like the cute little hockey puck pictured above for ambient light, using the exact same electronics kit.

The IQ light is versatile, good looking, relatively easy to put together, and in the public domain, so you can do whatever you want with it. Using just a single shape cut from thin plastic or thick paper, you can put together some pretty cool modern-looking polyhedrons. luciole works great inside of these.

We anticipate that we’ll be able to make the bare-bones kits available around May, with some beautiful cases to unveil at the end of the summer. If you are a product designer and/or an awesome crafter, and you’re interested in having some of your work featured on our site, get in touch with us at info [at] wyldco.com

What we’re saying here is basically that innovation and original design work is certainly not limited to university and corporate research settings. This isn’t a competitive threat, it’s awesome for all of us! Open-source hackerly devices like Arduino, Xbees, Makerbots, etc. are making it much easier to create cool tangible interfaces than it was when I started out back in 2004, so we can focus on great interaction design instead of trying to be electrical engineers (which we’re not).

We wrote about Open Source Hardware and hackerspaces in particular. While one is about licensing and the other is about physical space, both of these things allow for the dissemination, development and maturing of good ideas among researchers, professionals, hobbyists, community members, and all kinds of smart and motivated people from a variety of backgrounds.

So this doesn’t just make things easier for professional researchers in tangibles and in interaction design, it means that small-businesses and hobbyists are increasingly turning towards custom-made tangible, spatial, in-the-world interactions. Which is just how we like it.

Speaking of clients, we had some awesome ones this year! We were asked to lead the key early phase of User Experience design for Treatful.com, a web service that allows users to treat family and friends with personalized electronic gift certificates to excellent local restaurants. On a seven-week deadline, we made new prototypes weekly and conducted dozens of user tests. They launched a major update to their service, based on our specifications, in time for the holiday gift-giving season. It’s extra fun for us to work on a project that literally makes our mouths water!

Wyld Collective’s participation in P.o.E.M.M. (Poems for Excitable Mobile Media) also bore fruit this year, with Jason Lewis’s Vital to the General Public Welfare exhibition in Toronto last October. Wyld led the development of most of the interactivity behind these artworks, as well as the iPad and iPhone apps that let you enjoy them outside the gallery. “Speak”, “Know”, and “Migration” are free to download – check them out!

It looks like 2012 will be keeping us busy as well. Look for our article on “Research with a Hacker Ethos” in the upcoming March/April issue of ACM Interactions Magazine. If you’re going to be at CHI this spring, come to our panel on “Indy R&D”. And last but not least, over the next few months, we’re on track to introduce some hacktastic new products aimed at design-conscious DIYers.

At Wyld Collective we’re all about designing interactive systems. We combine years of experience in design practice and user research with up-to-the-minute knowledge of cutting-edge technologies. Our services include interaction design, prototyping, software development, and evaluation in both qualitative and quantitative flavors. Sometimes we even run workshops (bizarro game controllers, anyone?). If these skills sound like something you could use, drop us a line, tell us about your project, ask for an estimate, tell your friends. You know the drill.

Finally, we owe a big “thank you!” to the people who have helped make 2011 so successful for us: our clients, friends who’ve referred us, the people who have been willing and patient guinea pigs to our unfinished designs, and everyone who’s given us an opportunity to do something cool. We couldn’t do it without you!

Were Chipchase and those doing similar work really helping those in developing countries by creating better products for them? What if, instead, they were simply scraping local communities for big ideas and then riding them to big profits?

In other words, Chipchase’s admirable sensitivity to individual ingenuity, under the force of the corporate logics of his employer, can bend all to easily into theft of poor communities’ intellectual property.

These are uncomfortable questions for many of us to grapple with. I’ve done ethnographic and design work for huge corporations as well, and questioned whether I was selling out my participants. Though I was working in what most would call a developing region, the participants in some of my studies have been middle-class. They were already buying products from Nokia, HP, Intel, and Acer, and were gratified to see their purchasing power drawing those companies’ attention to their particular needs.

But there’s a big difference between the global middle class and the global working class, who must budget more carefully, and who are more vulnerable to exploitation. There is no easy yes-or-no answer here. For a corporate design-ethnographer to engage with the world’s poor risks exploiting them, while avoiding these engagements continues to silence them.

The article points out that the world’s poor are not passive victims of consumer technology:

Chipchase argues that critics of this process are themselves making a terrible assumption about the poor: That they’re simply victims, or, worse yet, that they’re dumb and can’t think for themselves–that they can’t decide what’s valuable to them, and vote with their dollars.

Chipchase’s statement is true as far as it goes, but it doesn’t go far enough, and it presents the reader with a false dichotomy: either the poor are victims or their empowerment lies primarily in their purchasing power: to buy or not to buy. A dichotomy such as this continues to underestimate the creativity and intelligence of people living close to the edge of survival: there is where their power lies.

So who is best positioned to design better products for poor communities: large corporations or those communities themselves? I’ll argue that this is a false dichotomy, and that the how of it matters just as much as who makes the products.

In Thailand, and many other countries, people on limited incomes find mobile phones to be a worthwhile expenditure. Yes, they’ve made a decision to buy or not to buy. But this is contingent on cellular plans being within financial reach. How is this achieved? Telecoms and government policy have some role in it, of course; different markets have different prices. But for now let’s focus on some practices of individuals and entrepreneurs around these products. In any mall anywhere in Thailand, and not a few street markets, you’ll find dozens of entrepreneurs who will unlock virtually any mobile phone for a low price. While most North American consumers allow their service providers to lock them in to using their service for a multi-year contract, Thai consumers are having none of it. People routinely change their phone numbers when they find a plan at a better price, and this increased competition helps to drive dirt cheap cellular service. Chipchase himself has presented footage of African hacker-entrepreneurs disassembling and reassembling SIM cards so people can carry two chips in their phones. I haven’t even gotten around to jailbreaking my iPhone. So now who’s the passive victim of corporate avarice?

What we designers and ethnographers need to be doing is this: Let’s recognize the strengths and weaknesses of local practitioners in these developing regions. Their strengths are many: collectively they are smart and savvy, creative, and unafraid to tinker with and reappropriate technology. Their knowledge of local conditions is better than anything a non-local corporation could hope to achieve, which means they’re probably making better decisions about how to adjust products to their needs. Their weaknesses: lack of resources mostly – money, power to determine policy, to move or stay put as they choose – and sometimes lack of formal education. (Of course, these are broad generalizations and your mileage will vary depending on the community you’re dealing with.)

We also need to turn our perceptual and interpretive powers on ourselves and our employers. As long as we aren’t actively aware of our own corporate cultures, means of production, and privileges, then we’re failing to understand half of the design process. What are for-profit companies good at? What are they bad at? Where can corporate and local practices complement one another rather than butt heads? One thing large corporations are really good at is sourcing raw materials cheaply, thanks to economies of scale. They’re good at quality control and efficiency and minimizing costs. They’re good at optimizing supply chains, when they want to be. They are not so good at anticipating every local situation that their products might encounter, or at understanding the good and bad ways that their products might disrupt existing practices and communities.

So how can we, ethnographers and designers, take advantage of the strengths in both local practice and corporate production? Here are a few strategies that we’re trying at Wyld Collective:

1. Partner with local organizations. Depending on your objective, these may be non-profits, governments, entrepreneurs, or mid-to-large sized businesses that have been operating in your target market for a good long time. Don’t just extract information from them. Consider letting them fine-tune your design, or work in tandem with them to do so.

2. Make kits instead of finished products; local sellers can add value by tweaking them for their own customers. This is similar to suggestion #1, but in this case you’re underdetermining your product and giving locals close-to-complete control over the finished product. This depends on availability of local resources and may work better for some products (e.g. lights) than others (e.g. cars). In cases where this works, you’re not crowding out local competitors, but using your strengths to help support theirs.

3. Make tools to enable others’ production. Here you’re really underdetermining what the end-user gets. Arduino (thought not designed for developing regions) is a good example of a product that is really an open-ended, infinitely appropriable tool. More particular to to developing regions, Ushahidi facilitates communication of regional trends, and alerts viewers quickly to potential human rights emergencies. These are tools for people to empower themselves, but they don’t do the work for them, nor do they overdetermine what’s appropriate for different situations.

You don’t have to pick just one of the strategies above – they’re complementary. And they require you to ask certain questions about your site, your market, your product, and your own design and production processes:

• What are some of the strongest local skills in our target market?
• What are our strongest skills?
• Which parts of this process would benefit most from scalability and mass production? (For example: electronic parts are much cheaper bought and produced in bulk, and might not need to vary as much as the external form of your product would.)
• Which would benefit more from appropriability and local production? (For example, the more we can produce locally, the less is added to the cost by import duties.)

All of these recommendations require designers and engineers and ethnographers to have some literacy in each others’ practices, and some trust in each others’ knowledge. And of course, we’re being awfully optimistic here: there will always be corporations willing to fleece the poor. But as skilled practitioners working within a capitalist system, we do have some ability to push product design in more ethical, more sensible, more well-designed directions.

A few months ago, we released a poem app named Speak, which is part of the P.o.E.M.M. series, made with Jason Edward Lewis at the Obx Labs. The original app for the iPhone and iPad was a single interactive poem written by Jason, and designed in collaboration with us. The poem is broken down, its letters randomly floating across the screen. The reader can touch and drag each letter, which then attracts the rest of the line it is a part of, allowing the reader to form and read the poem one line at a time.

Last week, we released version 2 of the app. As an experiment, we opened Speak to other writers to see what they might write for this specific interaction, transforming the poem into a poetic platform. To start, Jason invited four poets: JR Carpenter, Jim Andrews, David Jhave Johnston, and Aya Karpinska, who each wrote a text for the app. The poems will be released weekly starting June 1st, and hopefully more will follow.

Speak is available on the app store.

I spent the last few weeks polishing the What They Speak When They Speak to Me (WTS) iOS application I developed with Obx Labs, which I mentioned in a previous post. Developing a working prototype for an iOS application can be done fairly quickly, thanks to the tools provided by Apple and a growing list of libraries and engines, but the more time consuming part of development takes place later, working with and often against the features embedded in the iOS SDK to polish your product. This how-to is about one specific issue that arose during the development of WTS: capturing touches over a UIWebView without losing its functionality.

This short tutorial assumes that you know how to place a UIWebView (or other touch swallowing views) in your app, and that you are at the frustrating point of trying to catch touch events over the Web View to implement some interactive behaviour. In my case, I wanted to swipe the Web View left and right to show or hide it, similarly to how the Twitter for iPad app manages its browser tab.

We’ll start from scratch and go through the following four steps. You can jump to step 4 if you’re looking for the meat of this tutorial.

1. Create a new XCode project using the “View-based application” template.
2. Add the standard methods to manage touch events.
3. Add a UIWebView covering the main view.
4. Add a custom class that extends UIWindow to capture touch events.

1. Create a new XCode project using the “View-based application” template.

This step is self explanatory. From XCode you select from the main menu: File > New Project, and them “View-based Application” which is under the “Application” template folder. This is here mainly to have a common code base from which to start the tutorial; I named the project “CaptureTouch”.

2. Add the standard methods to manage touch events.

Before we get to the problematic UIWebView, we want to make sure that touch events get to the application’s main standard view. The new project you created in step 1 should contain a view controller named CaptureTouchViewController. In the implementation file of this view controller, add the four standard touch management methods:

- (void) touchesBegan:(NSSet*)touches withEvent:(UIEvent*)event {
    NSLog(@"Touches began");
}
- (void) touchesMoved:(NSSet*)touches withEvent:(UIEvent*)event {
    NSLog(@"Touches moved");
}
- (void) touchesEnded:(NSSet*)touches withEvent:(UIEvent*)event {
    NSLog(@"Touches ended");
}
- (void) touchesCancelled:(NSSet*)touches withEvent:(UIEvent*)event {
    NSLog(@"Touches cancelled");
}

At this point, if you build and run the application, you should see a gray background (the view), and clicking anywhere on the background will output “Touch began” to the console.

3. Add a UIWebView that covers the main view.

As mentioned before, we assume you know how the UIWebView works, so we won’t get into too much detail. All we need is the simplest UIWebView covering the application’s main view. We will add the UIWebView in the .xib file created by XCode, but first we need to add an attribute and outlet to the CaptureTouchViewController. Your CaptureTouchViewController.h file should then look like the following:

@interface CaptureTouchViewController : UIViewController {
	UIWebView* webView;
}
@property (nonatomic, retain) IBOutlet UIWebView *webView;
@end

With the outlet created, you can open the CaptureTouchViewController.xib file in Interface Builder. Open the “View” object, and then drag-and-drop a new Web View into it. The Web View should automatically expand to cover the whole view. Right-click on the Web View, and then link a “New Referencing Outlet” with the “webView” attribute you created above by clicking the “New Referencing Outlet”, dragging to the “File’s Owner” object, and then selecting the “webView” from the list that pops up.

At this point, you linked the interface to the “webView” attribute, but it is not loading any html. We will need one last bit of code before we get to the core of this tutorial, which will load a url to make sure the Web View is working correctly. After the application’s main view finished loading, the CaptureTouchViewController’s viewDidLoad: method is called. This is where we add the few lines that will load a url into the web view. Your viewDidLoad: method should look like the following after the changes:

- (void)viewDidLoad {
    [super viewDidLoad];

	//Load the request in the UIWebView.
	NSURL *url = [NSURL URLWithString:@"http://www.wyldco.com"];
	NSURLRequest *requestObj = [NSURLRequest requestWithURL:url];
	[webView loadRequest:requestObj];
}

If you build and run the application, you should see the web page. Everything looks fine, but if you touch anywhere on the screen, you’ll notice that the “Touch began” message from step 2 does not appear in the console anymore. The Web View swallows the touches to manage scrolling and displaying the magnifying glass if you hold down a touch over text, and it blocks touch events from getting to the view. The next step shows how to capture those touch events.

4. Add a custom class that extends UIWindow to capture touch events.

There are different ways to capture touches over a Web View. One would be to extend the UIWebView class, but Apple says you should not, so we will stay away from that solution in case it causes problem later. Instead, we are going to extend the UIWindow class, and capture touch events before they get propagated to the correct view(s). The first thing you’ll need is a new class, let’s call it TouchCapturingWindow, with the following header and implementation files:

#import <Foundation/Foundation.h>

@interface TouchCapturingWindow : UIWindow {
    NSMutableArray *views;

@private
    UIView *touchView;
}

- (void)addViewForTouchPriority:(UIView*)view;
- (void)removeViewForTouchPriority:(UIView*)view;

@end

#import "TouchCapturingWindow.h"

@implementation TouchCapturingWindow

- (void)dealloc {
    if ( views ) [views release];
    [super dealloc];
}

- (void)addViewForTouchPriority:(UIView*)view {
    if ( !views ) views = [[NSMutableArray alloc] init];
    [views addObject:view];
}

- (void)removeViewForTouchPriority:(UIView*)view {
    if ( !views ) return;
    [views removeObject:view];
}

- (void)sendEvent:(UIEvent *)event {
    //we need to send the message to the super for the    //text overlay to work (holding touch to show copy/paste)
    //NOTE: this used to be called at the beginning of this method
    //for the copy/paste and magnifying class overlay to work. As
    //of iOS5, it stopped working, and this code needs to go at
    //the end of this method.    //[super sendEvent:event];    

    //get a touch
    UITouch *touch = [[event allTouches] anyObject];

    //check which phase the touch is at, and process it
    if (touch.phase == UITouchPhaseBegan) {
            for ( UIView *view in views ) {
                //NOTE: I added the isHidden check so that hiding the windows doesn't catch events
                //and changed it checks if the touch is in the frame.
                //if ( CGRectContainsPoint([view frame], [touch locationInView:[view superview]]) ) {
                if ( ![view isHidden] && [view pointInside:[touch locationInView:view] withEvent:event] ) {
                    touchView = view;
                    [touchView touchesBegan:[event allTouches] withEvent:event];
                    break; //NOTE: this used to be a return in the previous version
                }
            }
    }
    else if (touch.phase == UITouchPhaseMoved) {
        if ( touchView ) {
            [touchView touchesMoved:[event allTouches] withEvent:event];
        }
    }
    else if (touch.phase == UITouchPhaseCancelled) {
        if ( touchView ) {
            [touchView touchesCancelled:[event allTouches] withEvent:event];
            touchView = nil;
        }
    }
    else if (touch.phase == UITouchPhaseEnded) {
        if ( touchView ) {
            [touchView touchesEnded:[event allTouches] withEvent:event];
            touchView = nil;
        }
    }

    //we need to send the message to the super for the
    //text overlay to work (holding touch to show copy/paste)
    [super sendEvent:event];
}
@end

This class is heavily inspired by Michael Tyson’s tutorial, with a few changes and some added notes about the implementation. Here’s how it works. The TouchCapturingWindow overrides the sendEvent: method of UIWindow to check if touch events should be sent to certain views instead of only the top view, which is more or less the default behaviour. If you intend to have multiple views in your application, you probably don’t want to have all of them capture touch events, so the TouchCapturingWindow provides methods (i.e. addViewForTouchPriority: and removeViewForTouchPriority:) to add and remove the specific view(s) you want to touch. Once you’ve replaced the standard UIWindow with an instance of this custom class, touch events will go through the sendEvent: method, and allow you to redirect them to the correct view(s) based on any criteria. In the above case, the only criteria is if the touch falls inside the frame of any of the views that were added to the TouchCapturingWindow.

First, you need to change the default “window” of your application’s delegate to use the new custom class. Open the CaptureTouchAppDelegate.h file, and replace the UIWindow class by TouchCapturingWindow; don’t forget to import the header, which should give you something like this:

#import <UIKit/UIKit.h>
#import "TouchCapturingWindow.h"

@class CaptureTouchViewController;

@interface CaptureTouchAppDelegate : NSObject <UIApplicationDelegate> {
    TouchCapturingWindow *window;
    CaptureTouchViewController *viewController;
}

//NOTE: After updating to iOS5 and the latest XCode, this line started showing
//a warning, so to remove it, simply rename TouchCapturingWindow to UIWindow.
//@property (nonatomic, retain) IBOutlet TouchCapturingWindow *window;
@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet CaptureTouchViewController *viewController;

@end

After you changed the window in the code, you’ll need to adjust the MainWindow.xib to also reflect this change. Open MainWindow.xib, and change the class of its window object from UIWindow to the new TouchCapturingWindow.

Now that the window can propagate touch events the way we want, we need to tell it which view to prioritize. In this case, we want the application’s main view to receive the touch events that would normally be blocked by the Web View covering it. To add the view to the priority list, you’ll need to modify the applicationDidFinishLaunchingWithOptions: method of the CaptureTouchAppDelegate. Just after the window is made visible, add the view using the new addViewForTouchPriority: method, which should give you the following:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Add the view controller's view to the window and display.
    [window addSubview:viewController.view];
    [window makeKeyAndVisible];

    //add the view to the touch priority list
   [window addViewForTouchPriority:viewController.view];

    return YES;
}

Conclusion

At this point, if you run the application, you can see that touching anywhere on the Web View outputs the “Touch began” message of step 2. You can now use the touch events to add some touch-based interaction to your application, but be careful not to conflict with the Web View’s features such as scrolling and text selection.

At the beginning I mentioned that I wanted to keep all the Web View’s features. This is accomplished by one short but important line of code. In the sendEvent: method of the new TouchCapturingWindow class, the line [super sendEvent:event] assures that the Web View receives the event before we propagate it to the main view. As of iOS5, placing that line at the beginning of the method stopped working, and it now needs to be at the end of the method. Placing it at the end keeps all the Web View’s features for iOS5, but does not show them for devices with

[super sendEvent:event];

On a final note, if you look at the sendEvent: method, you'll notice that touch events are propagated to a view only if the location of the touch is inside the frame of the view. This is a common behaviour, but there is no reason why you should always stick to it. You might want to check the state of a view to decide if the view should receive touches, control the view by touching outside its visual frame, or send event to a specific view only after the user tapped around up, up, down, down, left, right, left, right...

Download
CaptureTouch Xcode project (pre-iOS5)
CaptureTouch Xcode project (iOS5)

Related links
Michael Tyson's (A Tasty Pixel) trick for capturing all touch input
Satoshi Nakagawa's WebViewTappingHack
Mithin Kumar's post on detecting taps and events on UIWebView – The right way

The ethnographer deals with nuance, particularities, with rich and textured accounts. She aims to communicate experience in a way that defamiliarizes the familiar and refamiliarizes the strange. A good ethnography holds a distorted mirror up to our own ways of life. If the ethnographer is asked to distill their living interconnected account into the regimented format of design requirements (at worst, something that looks like a bullet-pointed list), that conversion does violence to the ethnography. For a more thorough discussion of this, read Paul Dourish’s Implications for Design.

From the designer’s point of view the account presented by an ethnographer looks too shifty and complex to get a handle on. It’s overwhelming, because to design is to act; it requires the confidence to intervene in a situation. The clarity and solidity of requirements help us feel brave enough to act without doubting ourselves too much. This may be an illusion but it’s better than being paralyzed by self-doubt.

One of my ethnographic engagements focused on the question of what slum mobility looks like. Let’s look at just a small and abbreviated, but sufficiently complex, bit of the ethnographic account: slum fires.

Most people in this neighborhood are squatters, which means they don’t own the land — though some families have been around for three or four generations. The infrastructure is spotty, since they’re not officially supposed to be there. Electricity, then, is often expensive because it’s jury-rigged, re-sold and marked up. If you’re behind on the bills your landlord will probably cut off your electricity first, but you can fall back on candles for lighting. Cooking usually happens in hot woks. So: you get cooking fires, and you get candles burning, and sometimes someone falls asleep without putting it out.

Building materials here are very flammable. A slum fire spreads fast. It burns birth certificates that prove citizenship, without which a child cannot attend public school in the country where I did this study. It’s an opportunity for the city to evict people, by simply denying them permission to rebuild. An opportunistic eviction escalates a disaster into a tragedy, because poor slum dwellers muddle along using support from a network of mutual exchange with family, friends and neighbors. This is not easily rebuilt when people are forcibly scattered.

As a designer, how do I make this better without accidentally making something worse? How can I achieve the clarity I need to design effectively without losing sight of the entire context in which I’m acting?

The humbling answer is that I can’t tackle that whole mess. Slum mobility, in its tangle of interconnected, undesigned moving parts, is as baffling and as alive as a human body. But the ethnographic account can help you see how the parts fit together. It can tease out where some of the important practices are — the places where a small change can radiate outward.

The metaphor I’ve started using to describe this is design-as-acupuncture. If you can intelligently select one small spot to focus on, you can design something awesome.

The design proposal that comes out of this story is simple: cheap, compact, off-the-grid lighting. LEDs are brighter than candles and non-flammable. Discarded scraps of solar cells can be gotten for cheap (see Gilad Lotan’s excellent instructable for more specifics). Shake-to-power flashlights also suggest a possibility for renewable power. The hardest part is probably figuring out how to make it affordable (ideally, a dollar or less). On the whole, this is a relatively simple thing to design and build, and can eliminate one of the common causes of slum fires. It’s simple enough to be produced locally. If it makes a difference, it would be because of its intelligent positioning in an interlocking net of practices, spaces, and vulnerabilities. Like acupuncture, it’s not about how pretty the needle is, it’s about where you stick it.