Accretion: the growing together of separate parts into a single whole.

Bonus definition! Excellence: the state or condition of being excellent.

Step One: Aggregation

I begin with the proposition that aggregation has been one of the key concepts of the past five years or so—a period that we might roughly call the “Web 2.0 era,” if we were so inclined.

You can’t discuss aggregation without touching on RSS. We’ve never seen the oft-forecast “year that RSS goes mainstream,” exactly, but that’s really because we spent a long time looking at the wrong metric. While the online population at large has never taken to RSS readers as a replacement for just visiting a bunch of sites, RSS feeds (often unrecognized as such) have become mainstream as a component of the Web sites we visit or even the engine driving those sites behind the scenes.

Digg and its brethren (whether social, curated, or hybrid) represent another take on aggregation: you’re visiting Web sites, but those sites are themselves explicit aggregations of content from across the Web. Recognizing that the amount of stuff being created on the Web increases at a dizzying rate, we have invested in tools to aggregate what is most interesting (for an arbitrary value of “interesting”) from many different sources and present it all in a single place.

And while it might not be immediately obvious, the API boom of the mid- to late-oughts also gave the aggregation mindset a significant boost. Because developers could directly access the data and functionality of a wide variety of Web sites “behind the scenes,” we got a new kind of aggregation, most clearly expressed in the mashup: “oh, you want the data from site X overlaid on the map from site Y?” No problem. “Now you want to see the pictures from site A and videos from site B that are related to the topics discussed on site C?” Easy enough, here you go.

Step Two: Accretion

Aggregation obviously has real value and isn’t going away, but I believe that in the coming five years we’re also going to be talking a lot more about accretion. Consider this: a few days ago I was in a room with about a dozen people from the New York tech/startup scene who were asked what they were interested in and working on. Three people (and I was not one of them) used some variation of the phrase “real time” in their answer.

I think that in the short term this means that a lot of people will be focusing on the “twitch reflex” end of real time, with tools that offer immediate, compact, and contextual feedback based on users’ input: think pitches along the lines of “it’s like {Twitter, Aardvark, Foursquare} but {for, with} {dog owners, movie times, hyper-local content, flavor crystals}.”

As we go forward, though, I expect that more attention will be paid to the idea that “right now” is only one facet of “real-time,” and that it’s very probably not the most interesting facet of real-time. We’re now used to aggregating data across services to the point where it’s almost taken for granted, but the growth of interest in (and technological capacity to support) near real-time services means that exploration of data accreted over time will become an increasingly big deal.

Any real time service must allow users to participate quickly and easily (reference once again Fred Wilson’s twenty seconds tweet), which means that each data chunk will be relatively small; what’s interesting about those little chunks, however, is that they aggressively blur the distinction between data and metadata. The concern for real time services is not getting users to provide a lot of data at any single point in time, but rather to provide tiny bits of data relatively frequently.

Foursquare is the easy example here: is a foursquare checkin “data” or “metadata?” Many—possibly most—checkins have virtually no content in the traditional sense. You’re not asked to review or even comment on the venue you’re at, you don’t have to say why you’re there or who you’re with…it’s just user, timestamp, and location (and you don’t even explicitly provide the first two). By the standards of a 2004 Web service this would be metadata, not data.

The value here comes in continuing use. A single checkin or single tweet doesn’t mean much outside of a very short time window, and that has been one of the common criticisms of real time services thus far: that the half life of each piece of data is too short and the “content” too thin for this stuff to have real significance.  And that’s true, as far as it goes.

It hasn’t gone far enough, though, because our first response has been to aggregate. Twitter’s trending topics and Social Great’s excellent trend tracking make a certain kind of sense out of this real time data, but I think that these are transitional. The big shift comes when we figure out how to make sense of the direction and velocity of change represented in these snippets of data that people are tossing out with a minimum of effort, consideration, and editing.

Web 2.0 brought us the 1% rule: of 100 people online, one will create something, ten will “interact” with that creation, and 89 people will just look at the results. If the next few years go as I hope and expect, those numbers are going to be upended. We’re going to be working with much, much more creation of much smaller things. We’ll still be interested in the aggregated “where are we all now?” but we’ll be paying just as much attention to the accreted “what routes did we all take to get here?”

What you put in your Web app dashboard is different from what you put in your emails, and different from what you put in your SMS messages or mobile app dashboard, and rightly so; if McLuhan had his act at all together, we can be confident that even if you try to make one size fit all you’ll fail. Probably miserably.

But that doesn’t mean that the lessons learned in one medium can’t be applied to another. Our example for the day is a service that I love: Songkick, the folks responsible for an ever-increasing percentage of my discretionary incoming going to live music.

Songkick allows you to track both upcoming gigs by performers that you already listen to and gigs that other Songkick users will be going to; this is great, as it simplifies the process of discovering new music (as human beings are still the best music recommendation mechanism out there), but it leads to a problem for the service.

Right now on Songkick I’m tracking 500+ performers, half a dozen venues, and ten other people, so everything associated with those performers, venues, and people is a part of my Songkick “tracker.”  That means that my tracker includes people going to gigs around the world in addition to the shows happening in my own back yard. The image below is a part of one of Songkick’s email notifications, and there’s a problem hiding there:

Songkick Tracker Email

Quick, which of those shows is happening in the New York and which in London? Yeah, I had a hard time figuring it out, too. All of the data is available, but it hasn’t been transformed into easily actionable information.

What’s really interesting, though, is that this is a problem that Songkick has already solved—just in a different medium. Take a look a the Web version of the tracker dashboard, which offers a superset of the information in the email:

Songkick Tracker Dashboard

The difference is clear: while the data being displayed is functionally identical, the SK crew saw that they needed to visually distinguish between the different classes of data they were displaying when they were thinking about dashboard design for a Web site: the color coding makes it relatively simple to scan through the data and pull out what you’re interested in…data transformed into information. Because email is a different medium, however, the lesson learned on the Web wasn’t carried through to the emails that contain virtually the same data set.

It’s a relatively minor complaint, but the underlying issue is well worth considering: think about the impact of the medium on your message, but don’t forget that some of what you learn can apply across the board.

On a related topic, one of the biggest issues for anyone presenting is getting a read on the audience: how is this going over? Do I need to pick up the pace a little bit, or slow down? Did they all stop listening five minutes ago? One excellent speaker I know builds in a number of jokes as his thermometer, evaluating both how much response he gets to a joke and how quickly that response comes.

There have been a number of experiments with integrating the audience backchannel into a presentation, but as much as I like discussion and exchange, if somebody has a well-constructed, well-rehearsed presentation I don’t want them looking at their laptop every other minute to check out the latest comments from the peanut gallery. I want the actual presentation, but I’d be interested in seeing what presenters could do with some form of audience feedback. Thus the visual backchannel is born.

You make a little device…or rather you make of whole bunch of them. It is perhaps shaped like a ball small enough to fit nicely in a single hand. When someone holds the device, their hand completes a circuit, and via the little wifi radio that you cleverly included in it, the device sends a notification of that change in state to a nearby server. For extra credit, have the device measure the force of the grip and send that data, as well.

You then hand out one of these devices to every audience member as they enter the presentation space, telling them to grip the ball when they’re interested and let go of it when they’re not interested.

All of this data is sliced, diced, and mashed together by the receiving server and presented as some sort of interesting (and very simple) visualization on a monitor that’s visible to the presenter. Something as simple as a graphical representation of how much of the audience is “engaged” and what the engaged/disengaged trend is could be both beautiful and extremely useful.

And from there you’ve got a universe of other interesting possibilities for data analysis and visualization available. Put a more granular view up on a big screen behind the presenter, too, if you want. And on the Web–why not? A site that compares the visualizations from a variety of presenters would be fascinating, right? Or an annotated engagement timeline of the next Jobsnote?

This would, of course, have the side effect of forcing livebloggers to decide whether it was more important to provide feedback to the room in which they are actually sitting or type their every thought for the whole Internet to enjoy, but I think that might actually be a good thing. [Please note that I deleted the joke about how being able to type with one hand while the other was busy may actually be a skill that most bloggers have mastered, as I felt it was in poor taste.]

Any questions? I’m looking in your direction, potential ITP 2009 show participants…

If we accept that Twitter is in large part a social technology, then we’re presented with a universe of questions about Twitter’s social character. At the most basic level, Twitter’s relationships can be either one way (I follow you) or two way (we both follow each other). One could look at a user to see what percentage of their relationships are mutual follows, but that doesn’t really interest me much, since I suspect there’s a lot of “oh, I guess I should follow them back” noise in there.

Where it gets interesting to me is when groups are exposed: not just you and me following one another, but you, me, and Dr. X all following each other. A mutual follow might just be someone’s Twitter etiquette (Twittiquette?) exposed, but a set of mutual follow relationships seems a more reliable indicator of substantive relationships.

Definition of a Twitter Set
A Twitter Set is a group of three or more Twitter users such that every member of the set follows every other member, and no other members exist for the set. Note that set members need not only follow one another. Also note that I’m leaving the question of whether @Scobleizer and @JasonCalacanis should count for this metric as an exercise for the student.

Why Track This?
I’m not sure. For me, I’m interested in tracking it (or rather, having someone else track it) for pretty much the only reason I ever do anything: it seems like there could be something interesting there; I don’t know what, exactly, but something interesting.

As a starting point, one could build some fascinating visualizations off of this data: seeing where sets exist, how big they are, and how they overlap would be fascinating. How many sets do users tend to belong to? What’s the largest set that exists on Twitter, and who’s in it? How are sets distributed across the universe of Twitter users? Really nice visualization fodder.

More Details, Please
I think you could also reduce this to an interesting metric that shows something (again, I’m not sure exactly what) about how different people qw( use establish expose ) relationships on Twitter. If we say that a user who is part of a single, closed set (i.e. all set members follow only one another) should have a value of one as a baseline, we could use something like this:

A = Total number of sets within the user’s Twitter relationships
B = Number of people that the user is following
C = Size of largest set within the user’s Twitter relationships
User’s Twitter Set Value = (A / B) * C

Since the number of people that the user is following still seems relevant, I’m inclined to explicitly include the following count in the expressed metric, like so:

If you and your four closest friends only follow one another, the “twitter set value” for each of you would be…
(1 / 5) * 5 = 1
…and I’d express that as Twitter Set Value (TSV) = 1(5)

My own case (eyeball estimate, haven’t checked real stats) would be something like:
(8 / 84) * 4 = 0.38
TSV = 0.38(84)

Again, I’m not sure exactly what it would mean, but I’d be really interested in seeing this in action…any takers?

Let’s call out the operative paragraph:

As someone who has shopped for electronics at Amazon.com, you might be interested in the Archos DVR Station Gen 5, which lets you record TV shows directly onto your Archos player.

Uh-huh. So since I’ve “shopped for” electronics (a phrase that lends weight to my suspicion that I’ve never actually purchased any electronics from Amazon, but rather just browsed some pages), I might be interested in an Archos DVR. An Archos DVR that will let me record TV shows directly onto my Archos player. That being the Archos player that I borrowed from my imaginary friend, I suppose. Oh, wait, I get it — I’m supposed to buy both an Archos DVR and an Archos player. Because I’ve shopped for electronics. Right.

New hire in the marketing department, Amazon?

Like all right-thinking people, I’ve followed Techdirt for years, and over the past couple of years Mike Masnick and I have exchanged a number of emails on various topics. I suppose I vaguely assumed that sooner or later I’d run into Mike in person somewhere along the line, but we’re just email acquaintances who share some interests, you know? There was no specific reason that we would plan to meet, so I never really gave it much thought.

Then last week I wondered aloud — via twitter — how much Mamoun’s falafel my father and I have eaten together over the past 36 years. Four days and an assortment of @replies and d messages later, Mike and I are sitting in Mamoun’s, eating falafel and chatting. Without Twitter, most (if not all) of the data points below would never have been exposed:

• I am a fan of Mamoun’s falafel.
• I live in New York City.
• Mike Masnick is a fan of Mamoun’s falafel.
• Mike Masnick happens to be in New York City this week.

Kind of neat, and an excuse for me to go eat falafel while talking to a smart person, which is always a good thing.

With Twitter, as with Tumblr, there’s an interesting strain of online community floating around. If mySpace is the ugly side of objective-free explicitly social software, maybe these “tools for creating user-defined community” are the up side of the deal. In both cases you build your own community (and therefore your experience of the tool) entirely based on who you follow — there’s no single “there” there (though I mean that in the best possible sense).

While I’m not yet clear on how this plays out on any grander scale (what happens when, with greater numbers of users, the volume of data flowing through makes users more inclined to limit input to only source they already know?) it’s a lot more fun than I expected to be along for the ride.

Give some thought to Kim Cameron’s work regarding identity, paying particular attention to “delegation coupons”.

Run through the writing that Dave Winer has done in the last couple of days on user generated content (UGC).

Consider the evolution of online community, with specific reference to the model suggested by Twitter and Tumblr.

Keep VRM in the back of your mind as you go.

The get back to me…there are some really interesting conversations to be had here.

By taking advantage of the basic interconnectedness of the Web, using that interconnectedness to make it easy to combine information that already exists somewhere, things like the FeedBurner/del.icio.us combination get past the idea that everyone must be able to easily create HTML documents in order to “contribute” to the Web.

In the years since I wrote that, del.icio.us and Backpack have happily replaced my homegrown shell script approach to saving links and notes in an easily accessible way, and a whole new world of tools that take advantage of “stuff that already exists somewhere” has appeared…let’s talk Twitter, Tumblr, and some miscellaneous related items.

Chapter One: Twitter
I created a Twitter account around the time of the SXSW explosion, but hadn’t used it at all until a couple of weeks ago. I saw its appeal in a setting like SXSW (“hey, look, X is in the presentation next door—maybe we can meet up later”), but wasn’t particularly interested in broadcasting the minutiae of my day to day life.

Then a colleague convinced me to give Twitter a fair trial, in part by acknowledging that he had a hard time figuring out what to twitter (tweet?) himself. So I’ve been giving it a shot, and come to a strange realization: I like it.

You see, about ten years ago I had a writing regimen: among other things, I had to document one moment per day. It didn’t have to be anything significant, but at some point during the day I had to pull out the notebook and record something. The side effect of this was that I found myself going through the day in a more observant and thoughtful manner. I was looking and listening a lot more, thinking more about what was happening around me.

And now Twitter has started to do the same thing for me. Don’t get me wrong: I’ve already done my share of it’s raining, and my butt itches tweets, but to put it in Holmesian terms I’m observing more, rather than just seeing. I even like the 140 character constraint: it’s very much of the moment to say it, but paring a thought or observation down to 140 characters is a great exercise in creativity.

Twitter has passed my first test for social software: it’s now useful enough to me as an individual that I want to keep using it. I may not be using Twitter the way one is “supposed to,” and I have a hard time seeing what value I’m adding to the collective with my tweets, but I’m going to stay with it.

Chapter Two: Tumblr
What is Tumblr, you ask? Well, when you come right down to it nobody’s entirely sure. Fred Wilson posted some thoughts on the question (with visual aids!) a week or so ago, but wisely chose to say more on what it’s like than what it is. Fred and Bijan Sabet tend to describe it with some combination of the terms “social,” “blogging,” “lightweight,” and “look, just try it, okay?”

What is Tumblr to me, you ask? Well, I don’t know either, but I’m intrigued. [And you can find anagrams of "lightweight social blogging" here, if you're interested. My favorite is "a belching gigolo's light twig."] Anyway, the social/reblogging aspect hasn’t particularly grabbed me thus far, so I feel like I’m missing the point on that front, but the “lightweight” has me excited.

In the most general terms, one could describe the content creation end of Tumblr as a strongly-typed blogging tool: a Tumblr post is one of seven things: photo, link, quote, chat, audio, video, or text. What immediately intrigued me about this is that it’s implicitly telling users that they don’t have to do the whole blog thing:

• You’ve just taken a neat picture and don’t want to write anything about it? Cool. Photo. Done.
• You just read/heard a great quote, but don’t want to annotate and unpack it? Excellent. Quote. Move on.

The Internet is littered with long defunct, three-post blogs in large part because “blogging” is generally viewed as “writing,” and therefore every blog must apparently carry the burden of high school English classes: What’s my thesis? Have I developed my arguments? Spelling counts! Jeez, haven’t I written 500 words yet? Tumblr tries to eliminate some of that friction by scaling down the ambitions of blogging; if you just want to post a picture, post a damn picture and don’t worry about whether it constitutes a “blog post.”

But Tumblr’s structure adds something else, as well. You see, Tumblr accepts RSS feeds as input. My Twitter account already generates a feed of my little text musings. My del.icio.us account already generates a feed of links I’m interested in. My Flickr account already generates a feed of my pictures. My blog already generates a feed of my longer-form writing (but more on that another time).

Then consider that with Disqus and IntenseDebate in play I’ve got feeds of many of the comments I make out there on the Web. With last.fm added to the mix I’ve got feeds covering the music I’ve been listening to, sliced and diced in a variety of ways. With a little bit of Applescript, the Tumblr API, and a cronjob on top of last.fm, I can automatically give Tumblr one of the songs I was listening to yesterday as an “audio” post.

Tumblr is becoming fascinating to me as a way to capture all of the stuff that I’m scattering around the Web (and my own computers, for that matter) in a structured way. With only a relatively small amount of setup work, I can assemble my own little lifestream and just watch how it evolves.

There are already tools out there to generate “lifestream” blogs (check out Kieran Delaney’s slick Simplelife plugin for WordPress, for example), but “creating another blog” doesn’t appeal to me, somehow…and this, I’d guess, is where the social aspect will come in to play. Whether it’s true or not, aggregating this stuff within Tumblr’s framework feels different from, and more interesting than, creating yet another blog.

As with Twitter, I have a hard time seeing what I’m adding to the Tumblr community, but I’ll give it some time. Perhaps after a while “reblogging” something won’t feel quite so much like a transparent plea for the poster to validate my presence on Tumblr by following me. I’ll figure out (how||whether) to incorporate my Tumblr dashboard into an already big pile of input. I’ll work out answers to all of the little questions that come up when playing with a new tool.

But however it works out, three and a half years from now there will be another set of shiny new toys to play with. Be sure to come back then and read the next post in this series.

OVERVIEW
The core of Vendor Relationship Management (VRM), in all its incarnations, is a respectful relationship between vendors and customers. VRM is not anti-vendor: at most, it is anti-business-as-usual.

While engaging in VRM does mean that vendors must do without some “rights” that are currently taken for granted, and their associated practices, VRM also requires that customers actively engage in the relationship, taking on the responsibility for communicating to vendors in a way that they can easily understand.

## START METAPHOR
A vendor/customer relationship based on today’s CRM places far too much weight on each party “reading” the gestures—the implicit statements and questions—made by the other, leaving little or no room for explicit communication. CRM “relationships” are like a newly-married couple that never speak to one another, relying entirely on body language and facial expressions, mood and gesture, to interpret one another’s behavior.

These non-verbal layers enhance communication, and help to create a rich, textured relationship, but without a foundation of clear, open, and explicit communication, these readings of the other party are guesses.

Each guess about what the other partner wants or needs from the relationship leads to another guess: do they like what I’ve done, or not? Would the other idea that I had have been better received? A model of the other partner is built, layer upon layer, and each party is engaging with the model of their partner, not with the actual person.
## END METAPHOR

VENDOR PERSPECTIVE
The benefits of VRM vary depending on what role one is playing in a relationship, and the goals of that relationship, but there are common threads. From a vendor’s perspective, each individual that they engage with is made up of more data points than the vendor could possibly hope to collect and interpret, and that’s a margin-eating problem; where CRM almost requires that the vendor’s “relationship” is with an impressionistic (and often out-of-date) thumbnail sketch of a person (as in the metaphor section above), VRM allows the vendor to engage with the actual person. The seeker and vendor agree to treat one another with respect, and (we hope) that allows them to be more open with one another.

Two other notes on the vendor’s perspective on VRM:

Many companies have entire divisions dedicated to purchasing. The idea that finding and acquiring what you need as efficiently as possible, taking advantage of your existing relationships, is one that’s immediately comprehensible to vendors. The existing language, models, and tools of corporate purchasing may be useful for informing VRM development and also for conveying the importance and benefits of VRM to vendors.

In addition, presenting VRM to vendors as a “framework” or “API” may be advantageous. Many vendors understand CRM as an umbrella term that encompasses many different implementations; we should make it clear that VRM is an analagous umbrella, providing ways to engage with current or potential consumers in a more effective way.

SEEKER PERSPECTIVE
From a “seeker” perspective, the problem seems a little more straightforward: you can never get back the two days that you spend figuring out which cell phone you want to buy and who to buy it from. If VRM can help you quickly and easily figure out what you want and communicate those needs/desires to the people who can fulfill them, VRM offers a real, immediate benefit.

Much of our behavior as customers is defensive: we ask our friends’ opinions, we search the Web for unbiased reviews, we compare vendors’ prices online, use disposable email addresses or fake profiles to get access to vendors’ special offers…because we see vendors’ interests as opposed to our own, much of our relationship with vendors comes down to simply trying to avoid getting screwed.

REPUTATION AND TRUST
While VRM is fundamentally about one-to-one relationships, it requires a superstructure of reputation in order to work well. What is the reputation of the vendor, customer, or prospect that I’m engaging with? What do the people (or vendors) that I trust think about them?

The importance of reputation and trust points to another key VRM issue: the reputation/trust concerns for any VRM data storehouse. In some VRM implementations a central data repository is likely to be necessary (or at least very desirable). Under what circumstances will it seem appealing and worthwhile to people to share data with a third party? To put it another way, is a big storehouse (vendor-neutral VRM data store) actually better than many little silos (vendor-specific CRM) if you still don’t trust the landlord? What can the landlord do to earn people’s trust?