this is aaronland

“What is the sound of one person using a platform?”

TALK TALK TALK TALK TALK

If you're around the Valley tomorrow I will be presenting a talk entitled The Scribblenet : APIs, Machine Tags and Magic Words — Building the Do What I Mean Engine, at the Bay Area ACM.

A few quick, sort-of related thoughts :

Anyway, here are the slides.

This blog post is full of links.

WTF Is On First?

This blog post is full of links.

Writing on the wall

Part One

My favorite act of abuse is writing in books — and, in this at least, I follow in illustrious tsteps. Mathematics would be considerably poorer were it not for the marginalia of Pierre de Fermat, who in 1637 jotted in his copy of the Arithmetica of Diophantus, I have a truly marvelous proof of this proposition that this margin is too narrow to contain. This casual act of vandalism kept mathematicians out of trouble for 358 years. (Andrew Wiles finally proved Fermat's Last Theorem in 1995.)

Libraries have an ambivalent attitude to marginalia. On the one hand, they quite properly object to people defacing their property. Cambridge University Library as a chamber of horrors displaying “marginalia and other crimes,” including damage done by “animals, small children and birds,” not to mention the far from innocuous Post-it note. On the other hand, libraries cannot suppress a flush of pride on acquiring an ancient text “annotated” by someone famous. Like graffiti, marginalia acquire respectability through age (and, sometimes, wit).

— Confessions of a Book Abuser, Ben Schott

Part Two

I never begrudged Simson his not wanting to release the source code to SBook. It was, and remains, an excellent address book but the thing that always spooked me was that you entered stuff as free-form text and application stored stuff as free-form text. SBook would then just magically parse the address for you, recognizing names and companies and all (most) of the vagueries of addressing things. Which meant that if you ever wanted to do anything with all that data outside of SBook you were left cold with the daunting task of figuring out how Simson built the damn thing.

Then he went and released the source code.

I know that Stikkit was not designed to be a general purpose address book. It has peeps but those seem like they are supposed to be more of shortcut, or a view, on the people you may have mentioned in the course of a note. For example, I can add little bits of the same person in different stikkits like this :

Squishy Carrots

name:aaron
phone:415-555-1212
                    
Shiny Bubbles

name:aaron
email:bob@example.com

As different pieces of information are added, the collection is aggregated in a separate stikkit for that person (and, yes, peep stikkits really are pink) : 

aaron

name:aaron
email:bob@example.com
phone:415-555-1212

This is good. It would be better if when I updated the peeps (pink) stikkit the changes were reflected in all the other stikkits but it is worth remembering that stikkit is not actually an address book.

It's also very easy to confuse the Stikkit address parser (see above) and the vCard export is missing all kinds of stuff (tags and unique identifiers in particular) from the vCard export tool.

Part Three

I mention all of this because I am trying to collect the names and addresses of bakers in Paris. This raises a few issues, most centered around the part where people (read: me) are lazy :

Poilâne
  1. It needs to be on the Internets. It needs to have an export API and, ideally, a variety of import endpoints.
  2. I'd like to share stuff and let others contribute, as well.
  3. But not with everyone.
  4. I don't really want to spend a lot of time marking up addresses; ideally I don't want to add any markup at all.
  5. It's not really an address book anyway unless you're going to start writing things like 16th St @ corner of don't order the soup.

This is the part where the Atom people start jumping up and down arguing that address books are really just feeds (a veritable river of who's on first) and everything should be an entry, while the microformat people almost choke imagining everything marked up in hCard.

Just for kicks, Blaine recommended I store everything in Flickr using machine tags.

Part Four

This presentation will review this trend across a variety of textual formats covering the areas above and describe them compared to their XML equivalents with their unique features, goals and limitations and their tradeoffs between simplicity, extensibility and validation. It will also discusses when text formats go bad, causing people to create alternate formats that generate them, when the design fails.

— <XML/> without the X - the return of {{Textual}} markup, Dave Beckett

You would be forgiven if you thought this post was about addresses.

Ultimately, it is about scribblability. It is the part of the papernet where people use tools (shared or not) to publish the stuff that interests them. Put another way, it is walking the line between making it easy enough for people to bother putting data in to a system and still useful enough to make it worth the trouble of getting it out.

del.icio.us remains a good illustration of this idea. A lot of time and effort has been spent trying to define a model of describing things, some of it good and most of it either specialized or pendantic or both. It's a hard problem but it also tends to be a problem whose solutions, whether it's a methodology or actual living breathing software, are often so complicated and boring as to ensure they are never used. Worse, many are prematurely optimized in to a state of brittleness that prevents any sort of iteration or revision; both reasonable expectations when defining the meaning of is.

By way of example, it took a really long time but eventually I realized that the only sane way to label paper file folders was with masking tape.

There's already been plenty of ink spilled on whether or not del.icio.us' tagging system is flexible enough to work with third parties or robust enough to preserve any meaning of value as it grows. For machines. The value of del.icio.us, for me, is the part where it is fantastically easy for people to add cues and hints (tags) to, in this case, links leaving the dirty work of assigning meaning for users to sort out USIN THEYR MINDZ!!!

Like magic.

Part Five

Magic email addresses — addresses that allow you to send content to a something other than someone's inbox — are similar in nature and probably the most useful thing about any web-based service, in a mobile context, while we wait patiently for better browsers and input models. The messaging application on phones (where there is little if any distinction between email and SMS) are probably the one piece of software designed for speed, at least relative to anything else the device does and the interface is mercifully lacking in bells and whistles. You enter plain unformatted text and not much of it either because you've never figured out how to use predictive text of you've bumped up against one of the many limiting agents that dictate the size of a message.

I don't think this is a bad thing, per se. As much as I love tiny computers and their ability to fit in my back pocket they are not always the right tool for the job. I want to write paragraphs on my phone about as much as I want to read anything longer than an essay on any kind of electonic device.

I once read Bruce Sterling's The Hacker Crackdown cover to cover on an old-skool Palm Pilot. It seemed like the right thing to do. It sucked. And hurt my eyes. And my hands. I would love to find a way to make the next 1, 200 page book I read small enough to squeeze in to my jacket pocket — cue the digital ink chorus — but making a book as small as it is large is no solution.

Imagine instead a 2D barcode associated with a subject, let's say a bakery or a restaurant, that encoded a magic email address; assume that the barcode reader is smart enough to recognize the messaging-ness of the address and trigger the correct application for sending-ness. One day, when barcode readers don't suck so hard, you will actually be able to Just Wave™ your phone over a printed barcode and enter quick notes (good; bad; don't order the pork) which are then published back to whatever service the magic email address hangs off of.

Whether or not you go back and edit, or expand on, those notes is moot. The point is you can. Or not. Later on, you can print a newer paper version before you head out the door and start all over again.

Part Six

Part Seven

Stikkit makes a big deal about magic words. They are to traditional natural language processing (NLP) what tags are to capital-O Ontologies. They make things easier.

Back in the days of the command-line interface, users were all Morlocks who had to convert their thoughts into alphanumeric symbols and type them in, a grindingly tedious process that stripped away all ambiguity, laid bare all hidden assumptions, and cruelly punished laziness and imprecision. Then the interface-makers went to work on their GUIs, and introduced a new semiotic layer between people and machines. People who use such systems have abdicated the responsibility, and surrendered the power, of sending bits directly to the chip that's doing the arithmetic, and handed that responsibility and power over to the OS. This is tempting because giving clear instructions, to anyone or anything, is difficult. We cannot do it without thinking, and depending on the complexity of the situation, we may have to think hard about abstract things, and consider any number of ramifications, in order to do a good job of it. For most of us, this is hard work. We want things to be easier.

— In the Beginning was the Command Line, Neil Stephenson

Part Eight

There is a limit to computer magic, though, because human language is also magic and computers are still dumb.

If there is anything that the 80/20 Rule doesn't apply to it is addresses. And recipes. If a machine makes a mistake with either the results are generally some shade of Bad.

So if we... dumb it down a little and think instead about how to describe — which really just means writing it down with an expectation of being able to find it later — a bottle of wine, we end up with stuff like this:

Traditional (WWW)

Semi-structured (Wiki)

{{Unti|Syrah|2003}}

Magic (NLP or simple)

Unti Syrah 2003

Magic (Insane)

Unti Syrah 2003

tag as unti, syrah, 2003, wine

For bonus points : Magic (Stupid).

Part Nine

You tell me which is better.

I've written the first two in the past. People like Simson have written the third. Every one else will probably use the fourth because it's easier (to scribble) than #2. If, like #3, it's a losing battle at least it is lost on your own terms.

Now think about addresses, again.

This blog post is full of links.

I am not a number

If you come to see me talk about the Papernet at XTech, this year, I promise I will have new and exciting stuff to say. Or, at least, a coherent narrative.

The Good

Post-it Communication

When I was in Helsinki, last summer, Chris and I were like a mutual appreciation club, going on about how useful it would be if people posted 2D barcodes in public places. Stores would post their hours of business; public transportation agencies would post schedules at bus stops; restaurants their menus.

Later, Kellan and I spent a lot of time on the shuttle bus down to the mothership bickering about barcodes. Barcodes should encode nothing more than URLs, he'd say.

I think he may have just been trying to get a rise out of me because he usually followed that up with some nonsense about everything being published on the web and microformats and a world where we do everything online and the pipes are never clogged and run pure with magic pixie dust.

It's not total crazy-talk. It allows you to publish (a barcode) once and send stuff on the fly based on circumstances : What time is it? Does the request contain a cookie set during a previous visit? Is it raining? If a user's device is smart enough to register content handlers for different MIME types, then the URL at the other end of a barcode could send back a calendar or and address book file that would be magically squirted in to the right place.

I really only have two problems with that scenario and, in fairness, I am probably wrong about both of them. One of them is the part about magic and not squirting but squirting in the right place. The other thing I don't like is that it means anyone who wants to use 2D barcodes has to have a website.

It means that anything I might want to do with a barcode can only happen online which is a little bit like cutting the baby's arms off instead of just swaddling it.

The Non Sequitur

Little pieces of poetry wrapped up in barcodes would be like easter eggs for the city.

In practice the whole thing would be horribly abused in about 25 seconds flat but it's also why you should be able to geotag Twitter posts.

I once encoded a recipe for baked beans, marked up as RDF/N3, in a single QR code. It worked, but was several orders of maginitude too dense for anything you might call a mobile device to read.

The thing I love the most about Nokia's barcode reader is that you can encode a vCard — their default format for business cards — and it will recognize that the text contains a phone number, a URL, even a postal code but it is not smart enough to figure out that it's looking at a vCard.

There's not really much point in generating QR codes half an inch or smaller on either side if you're going to try and read them with a cell phone.

The Bad

There are lots of different kinds of barcodes. So many, in fact, that apparently the various stakeholders in the industry must coordinate over some key decisions. Which could be a good thing, given their stated focus on things like rendering quality, error correction, whether barcode readers should be stand-alone or built in to a phone's camera application and even boring little details like aesthetics. By which they mean to say :

Outside, in a café, a mobile handset camera is pointed at an advertisement, poster, leaflet or beer-mat. In just one click, the user arrives at a webpage designed specifically for that location. No struggle with the compromised navigational systems of mobile websites; no wait – just the instant fulfillment of the user's needs. The spontaneity of the response encourages an internet connection there and then; the internet content is relevant to the precise time and location of the user; the advertiser can track exactly which piece of paper generated the user response – and the mobile handset has enabled a trouble-free and relevant experience of the web that is potentially more useful to website provider and user alike. And of course, the mobile industry benefits from increased usage of the internet over mobile handsets.

Wow!

It's a good thing I only have to wait until March 2007 to have my every need fulfilled. In a barco...I mean, a beer-mat. My problem with this scenario is not that I, in the course of the last few paragraphs, have suddenly decided that barcodes are a tool of the Man designed to commodif...I mean, fulfill my every need. Rather that the opportunity to do something useful and exciting is being crushed by the same kind of dumb, lazy and greedy lack of imagination that gave the world WAP.

Why so many people in the mobile industry continue to walk though life thinking that they are the benevolent overlords of happy walled gard...I mean, customer experiences where the insert your ad here runs free like beer-mats from a tap is, frankly, a mystery to me. It's a model that, given today's hardware and software limits, has a few years left but is ultimately doomed.

Either way, if people are too stupid to see that or just too greedy to care it is a brutally depressing situation.

Deep breaths.

If you accept the premise that working code always wins then the only sane thing to do is to ship your tool, or service, with as many different language bindings as possible or to make it so brain-dead simple that someone with an itch to scratch will do it for you over the weekend.

Which is why barcodes with URLs will probably make the most sense, at least in the short term. Proper web browsers are either available, in phones, or on their way. It's pretty obvious that the rendering engines will replace the existing GUI toolkits, even if we're a few years off still. When that happens we will have to face the ugly fact that JavaScript will finally be the so-called lingua franca.

Ultimately, we may still find ourselves in the same boat we are in today.

The problem is not whether the camera application should have an embedded barcode application. The problem is that in the same way people in the mobile industry reacted to the web by creating WAP rather than simply building decent web browsers, they are reacting to the fact that phones have become really small computers by selling platforms instead of fostering the possibilities.

In fairness, Nokia gets this better than anyone else. Their Internet tablets are a good example of being able to design and ship a tailored user experience while still allowing developers and hackers and tinkerers the flexibility to extend it for both fun and profit :

The D-BUS message bus system is used for applications and libraries to deliver messages to each another. ... The message bus is built on the top of a general one-to-one message passing framework, which can be used by any two applications to communicate directly.

But that's just a really long way of saying : They still have shitty cameras and no way to make phone calls.

 

The Ugly

Or :

Which looks like this:

$data = array(
	'street' => '475 Sansome',
        'city' => 'San Francisco',
        'state' => 'CA',
        'zip' => '94111',
        'phone' => '415-555-1212',
);

$addr = "{$data['street']} {$data['city']} {$data['state']} {$data['zip']}";
$url  = "http://api.local.yahoo.com/MapsService/V1/geocode";
$url .= "?appid=YahooDemo&location={$addr}";

$ch  = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$xml = curl_exec($ch);

$doc = new SimpleXMLElement($xml);
$lat = $doc->Result[0]->Latitude;
$lon = $doc->Result[0]->Longitude;

$qr_geo = new QR(array(
	'data' => '/path/to/qr/data',
	'images' => '/path/to/qr/image',
));

$qr_geo->encode(array(
	'd' => "http://geo.spum.org/?l={$lat},{$lon}",
	'path' => '/path/to/qr_geo.png',
	'color' => array(69, 139, 0),
));

$vcard  = "BEGIN:VCARD\nVERSION:2.1\n";
$vcard .= "TEL;VOICE;WORK:{$data['phone']}\n";
$vcard .= "ADR;WORK:;;{$data['street']};{$data['city']};";
$vcard .= "{$data['state']};{$data['zip']};\n";
$vcard .= "END:VCARD";

$qr_vcard = new QR(array(
	'data' => '/path/to/qr/data',
	'images' => '/path/to/qr/image',
));

$qr_vcard->encode(array(
	'd' => $vcard,
	'path' => '/path/to/qr_vcard.png',
	'color' => array(47, 79, 79),
));

QR.php is tiny OOP-ification of Y. Swetake's excellent qr_img libraries, with hooks for writing QR codes to disk and specifying a colour other than black. His (her?) release comes with both Perl and Ruby bindings and, at some point, I may sit down and port the code to Python. There is already at least one QR code generator for JavaScript.

The End

You are walking down the street with a big black marker in your pocket when you see a 2D barcode on the wall. Why wouldn't you start filling in the squares?

This blog post is full of links.