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 :
- I guess that went well. I have no idea really but I didn't say anything I wouldn't have said over drinks and people kept asking questions until the very end. Neil is probably right, though.
- Speaking of Neil, I'm not really sure that I was
asking for a
Flickr-style
email application except to say that every single piece of email software out there would benefit from aFlickr-style
API. That said, maybe this weekend, I will write something describing how I am archiving and, more importantly, searching email these days. Some time last year I gave up on trying to use MovableType for the job and opted for the less painful combination of shell scripts + Perl + Mhonarc + Namazu + a local web server. Apparently this is how the W3C deals with the problem too... - It stands to reason that the
papernet
is a subset of thescribblenet
. Or something like that. Really the only important thing is : The slide I borrowed from George's talk at SXSW, this year!
Anyway, here are the slides.
This blog post is full of links.
#scribblenetWTF Is On First?
This blog post is full of links.
#sxswWriting 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
Arithmeticaof 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 :
- It needs to be on the Internets. It needs to have an export API and, ideally, a variety of import endpoints.
- I'd like to share stuff and let others contribute, as well.
- But not with everyone.
- 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.
- 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
- The MediaWiki people can't agree on a standard mechanism for editing pages via email.
- Stikkit does not expose the magic email address for a page through their API.
- The Backpack API
does (but
its pages have no
magic
beyond formatting).
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.
#wallI 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
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.
#barcode