Conversation: Online/Offline

Standard

I received my Branch invitation this weekend, and made my first contribution.

It hasn’t changed my initial assessment that Branch could end up being something rather different from what has come before in very interesting ways, but it did cause a few more ideas to bubble up in my head.

The most interesting ones have been around the characteristics of conversations.

I hadn’t given it much thought before, but face-to-face conversations (at least the worthwhile ones) are largely sequential: only one person can speak at a time, and the other participants are listening. Each contributor in the conversation must take in (or at least sit through) what is being said by others, and wait for the opportunity to make their contribution.

And in a face-to-face situation, the overall direction of a conversation is guided by consensus: if the group cannot achieve a rough consensus on where the conversation should go, that conversation ends.

Online conversations generally don’t follow this model. Whether it’s comments on a blog post or a discussion in a topical forum, multiple participants can and do respond to each contribution simultaneously. In the time it takes to type a thoughtful response, three other people may have already added to the conversation. Participants don’t necessarily have complete information about the overall direction of the conversation when adding their part to it.

There’s also no requirement for consensus on an online discussion. If the participants don’t agree on what the conversation should be about, each sub-group can continue “their” conversation in the same location — they all still share a single thread/post/what-have-you — but it’s no longer really one discussion with a single, directed flow.

It fascinates me that thus far, the Branches that have felt most worthwhile to me have hewed much more closely to the offline model of a conversation than the current online model: each contributor seems to be (metaphorically) waiting their turn and then adding to the conversation as a whole. They feel much more measured, perhaps even “slow,” than most online discussions.

But the catch is how to encourage and facilitate that experience online.

When offline elementary school teachers and management consultants encounter the kinds of issues that online conversations encounter, they often reach for the “talking stick” — you talk while you’ve got the stick, and when you’re done you hand it to the next person. It’s crude, but surprisingly often it can help.

Is the talking stick a metaphor that has value for a class of online discussions? It’s limiting, it can be frustrating or even feel demeaning, but it accomplishes something.

If the goal is to collaborate on creating a directed, coherent discussion online, do the individual participants need to accept some new constraints?

Branch and the Pillars of Social Orthodoxy

Standard

Stowe Boyd posted some thoughts on Medium this morning, which included this:

I submit that this early version of Medium is a speculative design intended to challenge us to consider implications of the deep philosophy lurking within, rather than the test of a fully fleshed minimally-viable-product.

It’s interesting to consider the philisophical implications of a product, but I think it’s more interesting to consider the implications of the existence of a product that’s intended to make us consider the philosophical implications of that product. [My theory: it’s early adopters, all the way down.]

But the actual point is that Mr. Boyd reminded me that I have recently been thinking about the philosophical implications of a product: Branch.

I haven’t yet gotten my Branch invitation so take my opinion for what it’s worth, but from what I can see it looks like Branch is breaking with the mainstream philosophy of the “social” web in some interesting ways.

When you look at the social web that has developed in the past five or so years, a rough orthodoxy has been established.

First, in the context of a given service, you “follow” other users that service. There’s a bit of a schism around asymetric vs. symetric following (Twitter or Foursquare model?), but the overarching concept of following — which was relatively new and still a little weird in 2007, mind — is the standard. Even services that started without it (think Disqus, Kickstarter) have moved towards accepting the follow as a core social mechanism.

The second pillar of orthodoxy is the completeness of these follow relationships. When you follow another user of the service, you get everything they put into it. You can’t get just the graffiti pictures that I post to Instagram and not the ones of my kids, nor can you see my music posts in your Tumblr dashboard and not all the other crap: you get the whole person, all the time.

And the final pillar (closely related to the second) is persistence: once you have followed another user of the service they stay followed until you actively remove them. While you are establishing relationships in the context of the service, they are not relationships that require active maintenance. I may never like, heart, star, or otherwise validate your presence on the service, but that doesn’t matter: having stated my interest in you once, I need do nothing else.

So how does this relate to Branch?

Well, Branch is obviously a very social service: you’re asking a group of people to have a discussion on a particular topic. You’re indicating to those people that you’re interested in them and that you value their opinions, which is a key part of most healthy relationships, on or offline. And the discussion itself is visible to a much larger universe: because invitation is required, participation in a Branch discussion is making your relationships visible.

But to accomplish this very social undertaking, Branch is almost completely ignoring the established conventions of the social game. The conversations themselves are put at the center, rather than the participants.

You don’t follow other users, you ask them (or are asked) to participate in a specific discussion. The relationship being created is very focused and explicitly bounded. You don’t have to read the other Branch discussions that someone has participated in, nor they yours. And the relationship has no persistence at all: each new conversation requires a new set of invitations, an explicit renewal.

It’s difficult for me to come up with a more contrarian approach to a social service, but it could actually work. For all the people complaining about social overload and trying to build tools to manage it, very few are doing anything that’s really different. Path limits the number of people involved, but adheres to the social orthodoxy. People build tools to filter, mine, timeshift, spindle, fold, and mutilate your social streams, but they rarely question the principles underlying the construction of those streams.

I could be wrong, but I think that the Branch folks are building something that’s legitimately a part of the social web, but proposing an alternative to the current model. Branch seems very different from Tumblr, or Quora, or Twitter, but I’m not sure that’s a problem. This could get very interesting.

By Request: Flickr and the Instagram That Wasn’t

Standard

I recently asked on Tumblr whether there were any topics that people would like me to write about, and I received a number of interesting suggestions. Here’s the first:

highleverageinning said:

Flickr next. No joke. How to fix etc.

I’m taking this one on first both because it’s timely and because it’s relatively easy for me to address:

I’m the wrong person to ask.

Despite being a longtime Flickr Pro user, and (probably) holding the distinction of having the oldest unopened Flickr welcome message in existence [see below, unopened since December 16, 2004], I’m not really much of a Flickr user. I’m not a photographer, and I basically use Flickr as a convenient dumping ground that lets me visually scan my own pictures easily. While community is key to many people’s experience of Flickr, I’ve never felt part of a community there.

I genuinely have no idea what Flickr should do.

See? Short, easy answer.

But the catch, of course, is that I have some thoughts on what Flickr shouldn’t do. Or to be more precise, I have one thought on what Flickr shouldn’t do: Flickr shouldn’t try to build a better Instagram.

Yes, Flickr probably should have built Instagram before Instagram built Instagram. But it didn’t happen. Don’t try to play catch up. Flickr needs to  focus on fixing the problems that kept them from building the last Instagram before they have a shot at building the next one.

I note this because I read Mat Honan’s Flickr’s Engagement Problem May Be Too Big for Even Marissa Mayer. Which you should go read now, especially if you want to be able to judge whether I’m accurately representing Honan’s post. Which you should.

It an excellent piece and I’m nitpicking here, but I was bothered by this sentence regarding Honan’s test of the activity levels around Flickr vs. other services: “Perhaps more damning than the poor showing in terms of up votes was how ignored it was in real-time. It was only even viewed a total of five times on Flickr in that first hour.”

While I don’t think Honan is suggesting that Flickr build a better Instagram, exactly, it does feel like he’s suggesting that a viable Flickr is one that’s focused on a real-time, mobile, social photo experience as soon as possible, and that sounds to me a bit like trying to take Instagram head on rather than building a better Flickr.

It’s odd to say in these mobile-first, social-always days, but maybe Flickr would be better off building from their strengths. As Honan points out, Flickr “has great privacy controls, excellent display and sharing tools, makes a wonderful archive, and, despite years of neglect, enjoys tremendous good will.” What if Flickr stays focused on the web for a little while, and accepts (or embraces) a “slow photo” mindset against Instagram’s stream of consciousness, and Facebooks stream of…well, every-fucking-thing?

Could work. As I said: I really don’t know.

But I do know that Flickr shouldn’t try to build a better Instagram.

Identity : Anonymity :: Community : Network (?)

Standard

There’s been a fair amount of discussion around Google’s “real names” policy on Google+ in certain circles. Most recently in my stream, Fred Wilson pointed to Corey Doctorow’s post on the topic, and the discussion around that post crystallized some of what I’ve been thinking on the issue. To be specific, the crystal is:

The “anonymity vs. real names” debate is in large part a discussion of a very different issue: community vs. network.

Ages ago, in the days before Google+, the discussion tended to revolve around Facebook comments outside of Facebook. “If we implement Facebook comments,” the corporate presentation went, “it will improve the quality of the UGC on our site, because comments will be tied to users’ real identities. If people’s comments are linked to their Facebook profile, they will be respectful of both our content and other’s contributions, because a meaningful degree of accountability has been added to the system.”

The next slide of the powerpoint was inevitably the real money, though, pointing to the awesome traffic potential that came with hitching one’s buggy to the Facebook rocket: “because users can easily share their comments to their Facebook friends,” the presentation would continue, “we make better use of users’ existing social networks in our efforts to build traffic to the site.”

And there’s the rub.

Requiring a fixed external identity online addresses a very real concern, but it’s reactive. It is, in many cases and possibly at best, a response to the ease with which users can find a new-to-them site or service these days. It is, in an unfortunate number of cases, an attempt to shortcut the process of building a community in favor of importing networks, and then trying to preemptively create some order out of the mess that almost inevitably results from that import.

In Google’s case the network import in question was…well, Google’s, but I don’t think that changes the formulation to any meaningful degree: my Google+ circles are just as far removed from my gmail “contacts” list as the squares, lists, scenes, or cadres dreamed up by any unfunded Brooklyn startup.

The issue, in my view, isn’t whether giving users of a service the ability to be “anonymous” to other users of that service is harmful to that service — I maintain that UrbanBaby settled that question nearly a decade ago, in favor of anonymity — but whether an external identity requirement does anything positive at all.

Because so many people now have established identities and communities online, the idea that you can just tap into that pre-existing structure is incredibly seductive: you find one person who’s right for your new service and they bring a whole community with them.

The problem is that the network effect can help expand an established community, but it can’t build one. Drive-by visitors are generally more trouble than they’re worth, as many Dugg and Slashdotted sites will report.

Until people have a reason to take (credit || responsibility) for their activity on your site, you’ll have a real problem with bad apples, anonymous or otherwise. Once people do care, the community will make an effort to take care of problems whether or not they know the “real name” associated with that problem.

My “network” is made up of many different communities, and some of those communities don’t like one another very much. Assuming that pulling that entire, extended network into one central location is a good idea is…well, just not a good idea.

Bonus: any commenters who provide an explication of the “bartender” label that appears on Fred’s AVC comments get a free beer from me at the time and of their choosing (within reason). Bonus points for offering a (probably inaccurate) derivation of the term “86”.

On Making Stuff

Standard

For the past couple of weeks I’ve been spending whatever time I can spare on a little project: building kisttr, a Kickstarter Backer Tracker. It’s a pretty straightforward hack that allows you to “track” (or “follow”, if you prefer) a group of Kickstarter users and see what new projects they’re backing without having to visit each of their profile pages on the site.

As I was putting it together, a part of me couldn’t help but play out a little dialogue:

“So this thing just sends you a daily email that lists the new projects some people are backing on Kickstarter?”

“Yes. Though it does show them on a Web page, too.”

“And you spent two weeks building it?”

“Correct. Late in the evening, mostly.”

“It kind of sounds like a feature, not a product.”

“True. Very true.”

“And it actually kind of sounds like a feature that Kickstarter is likely to release themselves at some point.”

“Agreed.”

All of the points raised above are entirely valid. I fully expect that Kickstarter will sooner or later release an update that makes kisttr obsolete, it’s definitely a feature rather than a product, and it took me an awfully long time to build something that a competent developer could have banged out in a matter of a couple of days.

But to me, all of that is missing the real point.

Kickstarter may well release an equivalent feature, they don’t offer it right now, and I want this right now. Kisttr isn’t as elegant as I’d really like, but it works — and it’s a lot better than not having anything at all.

And while I’m a slow and clumsy programmer, after spending some focused hours designing and building this, I’ve remembered a bunch of tricks that I’d forgotten and learned a few new things, as well. [Amazon’s Simple Email Service is kind of neat, I’m an idiot for not making better use of CSS frameworks before, and so on.]

Today I have a better understanding of a few design and development issues than I did two weeks ago, and even though (or maybe because) I’m more of a “product” guy, that’s incredibly valuable.

When it comes down to it, it’s just fun — and wonderfully satisfying — to take a project from a barely articulated idea to reality. Making something that didn’t exist before is a real pleasure — even if what you’re making isn’t that big a deal in the grand scheme of things.

The further I get into this process (it’s still underway, since there are still a number of holes to be patched), the more strongly I believe that I get the real benefit from the process of building kisttr — the end product is just a little bonus.