Comixology and the future of connected commerce

Custom Burger ReceiptIt dawned on me recently that, not only are we in a period of great change and transformation, but that those of us who have been working on the web to make it a more social and humane place have only barely begun the process of taking the “personality-ization” (not “personalization”) and connectedness that we take for granted on the web into the offline world.

All at once, my sense tell me that things coming to a head, and, as Om Malik pointed out, we are at the end of an era. It’s anyone’s guess how the next chapter of the social web will read, but a few experiences lately got me thinking.

A connected Apple experience

I first saw a glimmer of this when in Boston, shopping at the Apple store for a USB charger. Upon checkout, I was asked whether I wanted a print copy of my receipt or to have it emailed to me. Reluctant to explain the “+apple” in my email address, I hesitated for a moment but submitted: “by email.”

The Apple employee looked at his screen, read back my email address and said, “Is that correct?”

“Yeah…” I stammered, somewhat surprised. “It is.”

Of course all they did was correlate my credit card number to the email address I’d previously had my receipts sent to. When I was shopping in San Francisco. Here I was in Boston!

Apple had recorded my email, associated it with my credit card (perhaps more than one), and then shared it with all their stores, providing me with a specific kind of convenience that few other stores — at least that I know of — have attempted. (Aside: And don’t give me any buts about privacy and correlations and any of that bullshit. Privacy has a certain kind of value and importance, but I’ve heard so little vision out of privacy zealots that it’s time think about the other side of the coin.)

Now, that small example of convenience may not seem significant on the surface, but it does suggest that new connections — between the world of brick and mortar identity and the realm of digital identity — are emerging, creating new opportunities for creative commerce.

Comixology and Isotope

James Sime by Bryan Lee O'MalleyMy favorite comic book store is located in Hayes Valley in San Francisco. It’s run by James Sime — someone who belongs in comics, much moreso than he belongs selling them. His shop is called Isotope and every month or so, as time allows, I stop in to pick up my “subscriptions” — known in the comic book universe as my “pull list”.

The pull list is a simple concept, essentially a list of comic books that I want to set aside on an individual or ongoing basis — that I’ll come and pick up later. Since new books arrive every Wednesday, it’s not terribly efficient for me to drop in just to pick up one or two issues, so the pull list is the best way to make sure I don’t miss an issue while stretching the time between visits.

The pull list is also a kind of personal relationship: I trust James to not only grab the titles that I’ve explicitly asked for, but to also suggest new books that I might not otherwise learn about. He also has to set aside inventory that might otherwise be made available to his walk-in patrons — even though I might ultimately decide, “Y’know, I think I’ll pass on this one”, so in that way, he’s trusting me to be a reliable patron.

Some time ago, James told me about a dashboard widget that he had discovered that let him see what comics were coming out soon. I checked it out — but then forgot about it — preferring the high touch relationship I had of visiting the store and browsing the shelves.

On a recent visit, James told me that he’d actually been in touch with the makers of the widget and that they were collaborating on “something big.” Having personally introduced James to both Twitter and Foursquare, I was intrigued… I mean, James has long had a blog, has presented at a BarCamp — as comic book retailers go, he’s about as 2.0 as you can get. And since he knows what a big web dork I am, his excitement told me that he was indeed on to something.

“They have an iPhone app,” he began, “called Comixology. It’s like the dashboard widget, but get this: I’ve been working with them on a pilot to hook up my store to their website.”

“Ok,” I said.

“So go to their website and create an account. Then search for my store. You’ll see a button that says ‘connect’. Hit that. From then on, whenever you add something to your digital pull list on the Comixology service, I’ll see it and add a copy to your stack.”

Retail Connection

“Wow,” I thought, “this changes everything.”

Connected commerce, activity streams and the point

It isn’t that my Apple experience or the Comixology service is the answer to question “what is the future of retail?”, but they outline the contours of the nexus between the social web and the real world.

Given what I’ve been working on in a round-about way on the DiSo Project, it is so patently clear to me that where Apple connects a credit card number to an email address, I see an OpenID associated with a payment gateway and a transaction dropbox that happens to be hosted by Google (that is, my email); where James and Comixology see a contextualized relationship management and inventory tool, I see an iPhone application that lets me buy physical goods, connect to a real life merchant of my choosing (based on his high-touch service), and then communicate my tastes and purchases to my friends and fourth-party services through activity streams.

Imagine: after a month of so assembling a good sized pull list on Comixology.com, I visit Isotope and James presents my selections, suggesting a few new books I might be interested in. I agree to give them a try, he updates my pull list on his Mac through the Comixology site, immediately updating on my iPhone. I review the list — everything looks good — and tap the “checkout” button in the app. Pre-loaded funds are immediately withdrawn from my Apple iTunes account; James receives an instant payment confirmation and I can take my comics to go without having ever reached for my wallet. Walking out the door with my nose in my phone, I uncheck a few comics from my transaction history and send the rest to my activity broker — which in turn pushes updates out to Facebook, FriendFeed, and to anyone else who is subscribed to my comic book purchases (yeah, like two people) — and in turn, they take my social recommendations, applying James’, and add some of my picks to their respective pull lists.

The whole thing takes about three minutes, with room for salutations.

This is buyer-mediated commerce (contrary to vendor-mediated), or what I might call “connected commerce.” This is one potential future for platforms like Facebook Connect to get real, and where I think identity, social, commercial and location technology will begin to hit their stride.

Where we’re going with Activity Streams

The DiSo Project is just over a year old. It’s remained a somewhat amorphous blob of related ideas, concepts and aspirations in my brain, but has resulted in some notable progress, even if such progress appears dubious on the surface.

For example, OAuth is a core aspect of DiSo because it enables site-to-site permissioning and safer data access. It’s not because of the DiSo Project that OAuth exists, but my involvement in the protocol certainly stems from the goals that I have with DiSo. Similarly, Portable Contacts emerged (among other things) as a response to Microsoft’s “beautiful fucking snowflakecontacts API, but it will be a core component of our efforts to distribute and decentralize social networking. And meanwhile, OpenID has had momentum and a following all its own, and yet it too fits into the DiSo model in my head, as a cornerstone technology on which much of the rest relies.

Subscribing to a person

Tonight I gave a talk specifically about activity streams. I’ve talked about them before, and I’ve written about them as well. But I think things started to click tonight for people for some reason. Maybe it was the introduction of the mocked up interface above (thanks Jyri!) that shows how you could consume activities based on human-readable content types, rather than by the service name on which they were produced. Maybe it was providing a narrative that illustrated how these various discreet and abstract technologies can add up to something rather sensible and desirable (and looks familiar, thanks to Facebook Connect).

In any case, I won’t overstate my point, but I think the work that we’ve been doing is going to start accelerating in 2009, and that the activity streams project, like OAuth before, will begin to grow legs.

And if I haven’t made it clear what I’m talking about, well, we’re starting with an assumption that activities (like the ones in Facebook’s newsfeed and that make up the bulk of FriendFeed’s content) are kind of like the synaptic electrical impulses that make social networking work. Consider that people probably read more Twitter content these days than they do conventional blog posts — if only because, with so much more content out there, we need more smaller bite-sized chunks of information in order to cope.

FriendFeed - Add/Edit ServicesSo starting there, we need to look at what it would take to recreate efficient and compelling interfaces for activity streams like we’re used to on FriendFeed and Facebook, but without the benefit of having ever seen any of the services before. I call this the “zero knowledge test”. Let me elaborate.

When I say “without the benefit of having ever seen”, I primarily mean from a programmatic standpoint. In other words, what would it take to be able to deliver an equivalent experience to FriendFeed without hardcoding support for only a few of the more popular services (FriendFeed currently supports 59 out of the thousands of candidate sites out there)? What would we need in a format to be able to join, group, de-dupe, and coalesce individual activities and otherwise make the resulting output look human readable?

Our approach so far has been to research and document what’s already out there (taking a hint from the microformats process). We’ve then begun to specify different approaches to solving this problem, from machine tags to microformats to extending ATOM (or perhaps RSS?).

Of course, we really just need to start writing some code. But fortunately with products like Motion in the wild and plugins like Action Stream, we at least have something to start with. Now it’s just a matter of rinse, wash and repeat.

A conversation about social network interop and activity stream relevance

Brian Oberkirch captured some video today of a conversation between him, David Recordon and myself at GSP East about social network interop, among other things.

Hot on the heals on my last post, this conversation is rather timely!

Adding richness to activity streams

This is a post I’ve wanted to do for awhile but simply haven’t gotten around to it. Following my panel with Dave Recordon (Six Apart), Dave Morin (Facebook), Adam Nash (LinkedIn), Kevin Chou (Watercooler, Inc) and Sean Ammirati (ReadWriteWeb) on Social Networks and the NEED for FEEDs, it only seems appropriate that I would finally get this out.

The basic premise is this: lifestreams, alternatively known as “activity streams”, are great for discovering and exploring social media, as well as keeping up to date with friends (witness the main feature of Facebook and the rise of FriendFeed). I suggest that, with a little effort on the publishing side, activity streams could become much more valuable by being easier for web services to consume, interpret and to provide better filtering and weighting of shared activities to make it easier for people to get access to relevant information from people that they care about, as it happens.

By marking up social activities and social objects, delivered in standard feeds with microformats, I think we enable anyone to run a FriendFeed-like service that innovates and offers value based on how well it understands what’s going on and what’s relevant, rather than on its compatibility with any and every service.

Contemporary example activities

Here are the kinds of activities that I’m talking about (note that some services expand these with thumbnail previews):

  • Eddie updated his resume at LinkedIn.
  • Chris listened to “I Will Possess Your Heart” by Death Cab for Cutie on Pandora.
  • Brynn favorited a photo on Flickr.
  • Dave posted a message to Twitter via SMS.
  • Gary poked Kastner.
  • Leah bought The Matrix at Amazon.com.

Prior art

Both OpenSocial and Facebook provide APIs for creating new activities that will show up in someone’s activity stream or newsfeed.

Movable Type and the DiSo Project both have Action Stream plugins. And there are countless related efforts. Clearly there’s existing behavior out there… but should we go about improving it, where the primary requirement is a title of an action, and little, if any, guidance on how to provide more details on a given activity?

Components of an activity

Not surprisingly, a lot of activities provide what all good news stories provide: the who, what, when, where and sometimes, how.

Let’s take a look at an example, with these components called out:

e.g. Chris started listening to a station on Pandora 3 hours ago.

  • actor/subject (noun/pronoun)
  • action (verb)
  • social object (noun)
  • where (place)
  • when (time)
  • (how the object was created)
  • (expanded view of object)

Now, I’ll grant that not all activities follow this exact format, but the majority seem to.

I should point out one alternative: collective actions.

e.g. Chris and Dave Morin are now friends.

…but these might be better created as a post-processing step once we add the semantic salt to the original updates. Maybe.

Class actions

One of the assumptions I’m making is that there is some regularity and uniformity in activity streams. Moreover, there have emerged some basic classes of actions that appear routinely and that could be easily expressed with additional semantics.

To that end, I’ve started compiling such activities on the DiSo wiki.

Once we have settled on the base set of classes, we can start to develop common classnames and presentation templates. To start, we have: changed status or presence, posted messages or media, rated and favorited, friended/defriended, interacted with someone (i.e. “poking”), bookmarked, and consumed something (attended…, watched…, listened to…).

Combining activities with bundling

The concept of bundling is already present in OpenSocial and works for combining multiple activities of the same kind into a group:

FriendFeed Activity Bundling

This can also be used to bundle different kinds of activities for a single actor:

e.g. Chris watched The Matrix, uploaded five photos, attended an event and became friends with Dave.

From a technical perspective, bundling provides a mechanism for batching service-to-service operations, as defined in PaceBatch.

Bundling is also useful for presenting paged or “continued…” activities, as Facebook and FriendFeed do.

Advanced uses

I’d like to describe two advanced uses that inherit from my initial proposal for Twitter Hashtags: filtering and creating a distributed track-like service.

In the DiSo model, we use (will use) AtomPub (and someday XMPP) to push new activities to people who have decided to follow different people. Because the model is push-based, activities are delivered as they happen, to anyone who has subscribed to receive them. On the receiving end, this means that we can filter based on any number of criteria, such as actor, activity type, content of the activity (as in keywords or tags), age of the action, location or how an activity was created (was this message auto-generated from Brightkite or sent in by SMS?) or any combination therein.

This is useful if you want to follow certain activities of your friends more closely than others, or if you only care about, say, the screenshots I upload to Flickr but not the stuff I tweet about.

Tracking can work two ways: where your own self-hosted service knows how to elevate certain types of received activities which are then passed to your messaging hub and routed appropriately… for example, when Mom checks in using Brightkite at the airport (or within some distance radius).

On the other hand, individuals could choose to publish their activities to some third-party aggregator (like Summize) and do the tracking for individuals, pushing back activities that it discovers that matches criteria that you set, and then forwarding those activities to your messaging hub.

It might not have the legs that a centralized service like Twitter has, especially to start, but if Technorati were looking for a new raison d’etre, this might be it.

This is a 30,000 foot view

I was scant on code in this post, but given how long it was already, I’d rather just start throwing it into the output of the activity streams being generated from the Action Streams plugins and see how live code holds up in the wild.

I also don’t want to confuse too many implementation details with the broader concept and need, which again is to make activity streams richer by standardizing on some specific semantics based on actual trends.

I’d love feedback, more pointers to prior art, or alternative suggestions for how any of the above could be technically achieved using open technologies.