In Spring 2014 I was driving through Boston on my way to visit family in New Hampshire. I started researching what some good lunch options might be along the route we were taking and decided to try out a new app I’d just installed called Jelly. It’s kind of like an instant, mobile app version of Quora: you can ask the app a question that gets broadcast out to your friends and friends-of-friends. Then, within a few minutes, answers are beamed back to your phone. Presto, I can get local recommendations for a lunch spot!

I’d recently finished reading Ethan Zuckerman’s Rewire. The book discusses how the scope of information we encounter—what ideas we’re exposed to—is limited by the boundaries of our pre-established social networks, an important aspect of the filter bubble phenomenon. I was thinking about how my lunch scenario fit into what I’d just been reading, me leveraging my social connections to solve the most first world of problems. And then this notification unexpectedly pops up on my phone, instead of the lunch tip I was waiting for.

Oof.

This was a notification from Josh Begley’s Metadata+, another app I’d recently installed. The app has a vague name, but its purpose is very particular. Whenever details emerge about a U.S. drone strike, it broadcasts a notification (also available via the Twitter handle @dronestream). It’s an invited interruption, a gentle reminder about how interconnectedness also includes 67-year-old midwives from North Waziristan.

Begley’s app is a great example of critical design. The first, and most obvious critique, is of the U.S. Government’s reliance on drone strikes abroad. The experience of living with this app shows just how infrequently we’re reminded that we are still at war, going on 14 years as of next Wednesday.

The other critique is about the capricious power Apple wields over digital culture. The name Metadata+ was chosen to obfuscate its purpose from app store reviewers, who rejected it repeatedly saying it was “not useful or entertaining enough.” Both Apple and Google have the last word on what software is deemed legitimate enough to install on a mobile phone. And as mobile phones increasingly become a default computing platform, it’s not hard to see the danger involved with censoring apps on the basis of political sensitivity. We’ve ceded control over the boundaries of permissible thought to corporate entities.

Which brings us to this past Sunday, when Apple decided to remove Metadata+ from the app store because of “excessively crude or objectionable content.”

Apple has a long and storied history of arbitrarily applying its decency policies to reject apps. As Sam Biddle has pointed out in Gawker, there are many, many other apps of questionable value that get approved all the time. It’s both a matter of inconsistency, and that political speech is being confined to those computers that happen to have keyboards and file systems.

But the larger issue, as pointed out by Zuckerman in his book, isn’t necessarily about what information is available to us, but rather that we care enough to seek it out. The removal of Metadata+ is about not being able to imagine why you’d want such a thing. And the extent that companies cater to our desires to be endlessly amused by safe and familiar material. We need these gatekeeper corporations to treat us more like digital cosmopolitans, to use Zuckerman’s phrase.

I was glad to learn from the Gawker piece that Begley is one step ahead of Apple on this one. He’s already released an identical version of the app, just with a different name: Ephemeral+.

Download it before it’s censored. Update: that one got pulled too.

Also, I highly recommend Life Alive for lunch, it’s a lovely vegetarian place in Salem, MA.

In a pair of recent posts, Andre Torrez outlined an idea for solving the “how do I get photos from my iPhone onto a website” problem. I like this idea, and I’d happily install this hypothetical Community Camera app if anyone ends up developing it.

The central mechanism for Andre’s idea is a new URL protocol camera: (similar to http:, mailto: or ftp:) that a simple camera application could claim control over. One such built-in protocol on the iPhone is sms:, which lets you easily direct users to send an SMS message. For example, clicking on this link (with URL sms:+12125551212) would switch you over to the SMS application with the phone number already filled in. Here is a handy list of other iPhone-supported protocols. But if you’re not reading this on an iPhone, pressing that link will probably give you an error message.

One of the good design aspects of hyperlinks is they’re not always expected to work, the web is chaotic and broken links are relatively harmless. So it’s certainly okay to offer these links even if they won’t work for everyone. An improved design would allow web applications to detect whether or not a given protocol can be used. That way I could write some JavaScript code to check whether camera: or sms: links are supported, and make the process much more seamless for users. As far as I know (correct me if I’m wrong), such a mechanism doesn’t exist yet. It exists! See update below.

The email workaround

One workaround solution, used by many web applications including Flickr, is to provide a special email address that allows you to upload photos as an attachment. The benefit is that every computer with a browser supports email links, smartphones and otherwise. The downside is the unwieldy sequence of steps you have to follow. In the best case scenario, a user has already saved the web app’s special email address to her contacts:

1. Switch to the Camera app, take a photo or find the one you want from your library
2. Press the “utility button” and choose “Email Photo”
3. Fill in the email address from contacts and press send
4. Switch back to the browser and wait for the attachment to be received by the web app

A number of factors complicate this process, starting with the initial messaging. The natural thing to say is “Email a photo to upload,” linked with a mailto: URL protocol. But on the iPhone you can’t attach photos from the Mail app, it only works from the Camera side of things. So that “Email a photo” link should probably go to a page that explains the process outlined above, including the important step zero “add our special email address to your contacts.”

Email uploading requires that you’re willing to read a bunch of steps, understand them, and follow them. Additionally, the web application is left with no button that initiates the process and no way of giving feedback about whether it worked or not. If you reload the web app and you see your photo, then it worked. If not, maybe you’ll get a email bounce message. It’s a process that works okay for experienced users, poorly for novices, and that fails ungracefully.

Plus there is the implementation challenge of receiving and parsing email, which is kind of a pain in the ass. As an alternative to Andre’s plan, if somebody wants to write a general purpose email-to-upload service, I would find that pretty useful. Or does this exist already? I haven’t looked very hard.

Compare those steps above to the camera: method (including step zero, “install the Community Camera application”):

1. Press the “upload photo” link, with its “camera:” URL protocol
2. Using the native app that appears, take a photo or choose one from your library
3. When finished, the app switches you back to a page that has useful feedback

This is a better user experience, but it does require that someone go and write that native camera app (and that I install it). And unless there’s some way of checking for camera: support, even this will require some additional explanation.

Multimedia Messaging Service

Yet another solution can be found in SMS, or its more advanced permutation MMS (Multimedia Messaging Service). Using the sms: protocol mentioned above, I could create a link to sms:email@example.com that behaves almost exactly like the email upload method, while avoiding some of its complexity. On the iPhone, you can attach photos from the Messages app, and you can send MMS messages to an email address. And since there’s a link that initiates the process, it allows web apps to give some feedback on the page in response to a click event.

The downside to this method is that it requires the user to have a mobile plan with reasonable rates for sending MMS messages, and could fail ungracefully for users who aren’t fully informed about their mobile plan.

In any case, writing all this up has made me realize web browsers should let you detect whether a given URL protocol is supported. Browser makers, please build that into your next release!

Update: Andre tweeted a clever trick for detecting URL protocol support! Here’s how it might work in PHP:

<?php

// This will only work if the sms: protocol is supported
header('Location: sms:email@example.com');

// If not, fall back on this other page
echo '<html><head><meta http-equiv="refresh" content="0; url=sms-not-supported.html" /></head></html>';

?>