“Tumblr’s Killer Feature”, and the mixed blessing of comments

May 22, 2013

I’ve largely neglected this blog over the past couple of years, especially since Google Wave got canned. My time right now is mostly spent on my new startup, Querki — folks who are interested in the details should check out its development blog.

But I’m still quite interested in the topic of online conversation, and so I had to post a link to this recent article from my friend Siderea. She makes a very good argument that comments are *not* always a good thing — and that, indeed, a chunk of Tumblr’s success can be attributed to the fact that it decided to not have them.

Well worth reading and thinking about. The upshot isn’t that comments are inherently *bad*, mind you — but that the presence or absence of comments, and how they are managed in an online system, will have strong effects on how that system behaves. There are costs to comments, which aren’t obvious unless you look carefully.

Or to put it more concisely: decisions have consequences, and the decision of whether or not to include comments can have *big* consequences. So don’t make that decision casually…

So what *should* the identity architecture look like?

February 1, 2012

[Crossposted to Google+, LiveJournal and Art of Conversation. That, in and of itself, illustrates some of the points I'm making.]
I’ve posted a lot (mainly on Google+) about the problems with the way Google is handling identity, and the various dangers of it. The just-linked article describes neatly why Google wants to mess up the identity architecture. But it’s worth spelling out the alternative, and how it should work to be best for the users.

I’ve been meaning to do a long writeup for months now, but keep getting distracted, so here’s the back-of-the-napkin summary. Consider it a sort of technical manifesto.

(Yes, this is the short version. It’s a quick and dirty writeup, just the spark for a lot more discussion. And most of it isn’t that novel: others have talked about it, but haven’t gotten far enough yet.)

There are, in principle, four principal layers in a well-constructed Internet identity architecture. I’m not going to go into the fine details, because from this viewpoint they don’t matter as much — what really matters is how they relate to each other. Suffice it to say, none of this is easy, but it’s all technically feasible if folks collectively want it enough.

All of these should be talking to each other through *open* protocols, with no back doors. That’s extremely important: the point of the exercise is that the individual should be able to control each of these layers him or herself. Even more importantly, no single company should be able to lock you into their stack: if you really value your privacy highly, you should get each of these from separate companies.

(I can’t overstate the importance of this. The success of the Internet has largely been due to its embrace of open protocols like IP, TCP, HTTP and so on. It is a travesty that the social network space has festered without them like this.)

The layers are:

Layer 1: Identity — this is the simple statement of “this is me”. Crucially, I should be able to have multiple of these, defined however I like. In my own case, there’s “Mark Waks” (the professional / business identity) and “Justin du Coeur” (the social / club identity). These Identities may provide additional details such as name, gender, or what-have-you, but don’t need to: all they really need to do is provide an authentication mechanism.

We already have Layer 1, in a couple of different forms. There are SOAP-based versions in the form of the WS-Security stack, and those are fairly elegant and well designed. In practice, OpenID is cruder but much more prevalent, works adequately for many purposes, and is used a lot. (Although not nearly as much as it should be.)

Layer 2: Social Grouping — this is the notion of G+ Circles, FB Lists, LJ Flists, and so on: groups of people that you define. These Groups may be public (everyone can see their existence) or private (only you know they exist). A Group is owned by one or more Identities, and contains any number of Identities. Note that a Group does *not* contain people, it contains Identities. One of the core principles here is that people know each other as Identities; how much they know about the relationship of a person and an Identity is a relatively private matter. (That is, lots of people know that “Mark Waks” is “Justin du Coeur”, but that should be a decision I control, not enforced by the software. The former should be in groups about these sorts of technology matters, the latter in discussions of the SCA and fandom.)

There have been some stabs at doing this properly, at least to the extent of sharing group information between applications. I don’t get the feeling that anybody has taken it seriously enough yet, and some providers (notably Facebook) deliberately make life difficult. But it’s been examined a lot.

Layer 3: Application — this is conceptually the top of the stack, but it interacts with the other layers in fairly subtle ways. This is all the stuff you can *do* online. In principle, all functionality belongs here, and shouldn’t get mixed in with the other layers.

Most systems get this wrong, mixing everything from personal information to chat into the Identity layer instead of formally separating it via APIs into a consistent Application layer. In particular, the big providers tend to treat applications as what everyone *else* gets to do, while privileging their own stuff. People have always objected when Microsoft does things like that; there is no reason for companies like Facebook and Google to get let off the hook.

There are some nascent proto-standards for this sort of thing, but I haven’t seen much agreement yet. It’s not going to be real until multiple companies are hosting applications using the same standard, and a fair number of companies are writing applications using it.

Layer 4: Aggregation — this is the elephant in the room, that everyone prefers to ignore, but it’s central to much of the privacy problem.

The thing is, if you really care about your privacy, you need to be able to control how your Identities relate to each other. The Identity provider, the Grouping provider, the Application provider — none of these should have to know about all of your Identities. Moreover, if one of them *does* own the collection of Identities, then they own you in a sense, and we fail the key objective of giving you control over your online world.

This is the heart of the various Google problems — I haven’t yet figured out whether they are being deliberately obtuse about this problem, or really don’t get it, or are struggling with its implications and (typically of Google) refuse to say anything at all until they have the one true solution built in-house, and are simply refusing to engage properly with the wider community. It was the heart of the issue with the Real Names policy (if everything has to be under a single real name, you get aggregated whether you like it or not), and it’s the heart of the issue with their new privacy policy (since it is now clear that you can’t separate your identities simply by using different apps).

Now of course, you *can* deal this today, by creating completely separate accounts and never letting them touch each other; that’s often recommended. But it’s a blithe non-answer, because the simple truth is that that’s horribly inconvenient. There simply isn’t good tool support for it, so at best it’s clunky.

This is the bit that’s actually technically challenging, because it affects the way the rest of the stack works. In principle, you want to be able to aggregate your *views* of applications — for example, be able to see all of the conversations that include all of your Identities in a single place. But doing this while getting real privacy means that the Applications have to be built in such a way that they can’t accidentally “leak” the relationships between the Identities, and that’s tricky. Still, it could likely be managed with a well-controlled environment, with well-defined APIs.

Separating things into clear layers like this, communicating via clear APIs, would improve the online social world in a lot of ways. It would level the playing field, letting in lots of competition in each of these spaces; at the same time, it would make it more economical to build new applications if you didn’t have to rewrite them for each social network.

And I should be clear: it’s entirely reasonable to cheat a bit. So long as a social network allows in outside versions of each of these protocols, there is nothing at all with it offering a full stack of all of them, integrated to make it easier for a naive user to get involved. Yes, there are some market risks with that sort of collusion, but let’s get real — most people want convenience, and do *not* care about things like privacy or openness. (Yes, they should. But the world doesn’t run on nice ideals.)

Why doesn’t it just happen? Plain and simply, because the above architecture doesn’t offer an obvious way to become a billionaire. In that, it’s much like the Internet itself. As an individual, you *want* the social network to be a commodity, the same way that the Internet is. But companies want to lock you into their walled gardens, because that’s how they get rich.

History points the way, though. Originally, the networks themselves were walled gardens — companies like Compuserve and Prodigy tried to lock you into their gardens, providing lots of features but not letting you walk outside. We didn’t put up with it then: we collectively instead went for the messy but inter-connected Internet, and those companies basically wound up in the dustbin.

And there’s no reason for us to put up with walled gardens now. The very fact that Facebook and Google+ (and Livejournal and and and) mostly don’t talk to each other illustrates how broken things are. That’s because each of those companies, ultimately, wants to own you and profit from you. We need to get away from that, and not *let* ourselves be owned.

How do we get there from here? Honestly, a lot of hard work on many peoples’ parts. Trying honest prototypes and experiments; agreeing standards; ultimately, building a system that does all the sorts of stuff that Facebook and Google+ do in a more open way. The public isn’t going to move away from them because of airy principles; they’re only going to move if we can build an alternative that is *better*, and demonstrate that to them. That’ll take patience.

But I do think it can be done — moreover, I think it *will* happen, because it is closer to what people want. Folks are pretty fed up with the split between the various social networks: it’s a real inconvenience for many people. It’s time to start building The Social Network, the social level corresponding to the unified Internet, so that we stop having to choose to fragment.

(And yes, I’m gradually talking myself into rebooting CommYou, with a radically different business plan…)

Twitter as the new chain letter

July 13, 2011

I just got the following retweet:

Help @SesameWorkshop raise money to promote #HealthyKids! For every RT of this message, @SamsClub will donate $5! Thanks for your support!

Let’s assume that this is real (it seems plausible, anyway, given what I can find online).  And granted, it looks like a good cause, and very well-intentioned.

But would anybody care to place any bets on when this chain-tweet will ever end?  Newer social media, with one-click access to resharing, does look likely to make chain letter memes even more dangerous and ever-spreading than they have been historically.

Although it does seem like an interesting challenge.  What would be the perfect chain-tweet?  It would need to tug at heartstrings, look deeply plausible, have no obvious end goal or date, and still fit into 140 characters.  The above is quite good: can folks do better?

G+: Circles vs. Identity

July 11, 2011

All the conversation about social networking right now is of course about Google+.  I’m not going to bother recapping that: most of you know about it (and I think that XKCD summed up the current state pretty well), and a lot of you are already on it.  They do a lot right, and I fully expect it to improve rapidly, but let’s talk a bit about the biggest goof that I’ve seen so far.

The big deal about Google+ is the notion of “circles”.  These aren’t nearly as revolutionary as they’re made out to be (from the thousand-foot view, they’re similar to Facebook’s Lists), but they’re unusually well-executed and well-integrated.  The key observation Google made, correctly, is that most people run in multiple circles, and that those circles need to be front-and-center to the experience, not considered a minor detail.  I put a lot of information online, and different information should be shared with different circles.

So why, for heaven’s sake, do I have only one profile?  I suspect that the answer is that they simply tied into the existing Google Profile mechanism, and that they have been too influenced by Facebook.  But seriously, it indicates that they haven’t thought their own key insight through properly.

The thing is, for many people — possibly most — circles are more than just groups of people.  It’s not just that I am sharing different things with those people, it’s that I am potentially a different person to those people.  And I don’t mean in some sinister way, I mean the routine stuff: it’s almost cliche to say that we present multiple faces to the world, and it’s kind of astonishing that that hasn’t been properly recognized.

For me personally, this is a relatively minor detail: I’ve never tried to keep much separation between the real-world Mark and the better-known nom du SCA and plume and stuff Justin.  But for a lot of people, this separation really matters.  A common example or two:

  • I have many friends who participate in alternative lifestyles of one sort or another.  For many of them, it is deathly critical that they keep that well-separated from mundane life and especially from work — in some cases, crossing those identities could be a career-ender.
  • Almost every teenager is on social networks nowadays.  And let’s get real: most of them want to maintain a clean separation between the family side of the network and the friends side.  That’s normal and healthy — modern parental paranoia aside, teens need space to learn and grow on their own.
  • One flap that’s blown up pretty seriously lately surrounds the question of gender identification.  That points up the fact that these different identities potentially don’t publicly identify the same way.  Specifically, I suspect that some of the women I know would very much like to have multiple profiles, some of which identify as female (mainly for friends) and others which are specifically gender-neutral (for public consumption).

There are other examples, but it all ties together.  Google has bought into Facebook’s dreadfully mistakenbelief that you can and should only have one identity online, that it must be associated with your real name, and that it must be shared among all your circles.  This is uncharacteristically dumb of them: there is no good argument for it, and lots of reasons — the above and more — to kill it.

So here’s a specific gauntlet thrown down to Google: get the identity equation right.  You got conversation mostly right with Wave; you’ve gotten a lot of the social interactions right with G+.  But your identity mechanism is just plain broken.  People should have the ability to have an arbitrary number of identities, and the requirement to tie those publicly to real-world identity should be just plain scrapped.

(And let’s be clear here: I’m not calling for anonymity.  Anonymity is death to most social environments online.  I am calling for pseudonymity to be officially permitted and encouraged, so that people can present the appropriate face to the appropriate circles.)

Opinions?  Do you present multiple faces to the online world?  Would you use multiple profiles, if the option existed?

Task-oriented conversation is demonstrated again

November 8, 2010

Here’s an interesting little article in Ars Technica a little while ago.  The upshot: people having conversations via SMS/text follow pretty much the behaviour patterns you would expect from a focused conversation.

Basically, they built a mathematical model that describes what you’d expect from two people having a conversation that is about something — an initial burst of activity, then gradually trailing off — and then compared that against real-world SMS traffic data.  Not too shockingly, with some adjustment of tunable parameters, it matched.

There isn’t anything too surprising here, but there’s an important ramification: they’re playing with the mathematics that underlie conversation.  Task-oriented conversation follows some fairly regular patterns, and they’re expressing those patterns.  This likely has implications for people building conversation systems, since it gives you an idea of what to expect and how to optimize for it…

Constructive

October 25, 2010

This was posted recently, in the always-excellent webcomic XKCD:

And what about all the people who won't be able to join the community because they're terrible at making helpful and constructive co -- ... oh

As always when XKCD is at its best, it’s both funny and thought-provoking, and quite on-target.

Here’s the question is raises, though: what’s the comment equivalent of the Turing Test?  Is the issue “bot or not”, “spam or not?” or “helpful or not?” Most spambots would fail the test described here; would human-generated astroturf?  Is “constructive” the right measure to use, to distinguish between “should be posted” and not?  It might be — indeed, the product-placement industry is almost based on this concept, and it’s better than simply asking “Do you think this is a bot?”.  But now I find myself looking for the best word to usefully express, “should this be here or not?”

To Bundle, or not To Bundle, that is the Question

October 21, 2010

I just got an unusually formal email from Google, saying that Google Groups is dropping a lot of functionality.  Specifically, they will no longer support customized welcome messages, pages or file storage for groups.  Essentially, they are going to stop pretending that they are competing with Yahoo Groups, in favor of trying to do a better job on mailing lists and forums.

They are quite clear, however, that you can still have group files and pages — it’s just that you should do files through Google Docs, and pages through Google Sites.

On the one hand, this actually makes a good deal of sense.  One of Google’s big problems is that they have lots of systems that are overlapping, or often completely redundant.  Having two separate file-management systems is a bit silly, so refactoring and merging them makes sense.

That said, I worry that they’re missing a key aspect of group identity.  Saying, “You can upload a file, and make it accessible only to a group” is not the same thing as saying, “You can upload a file within your group”.  The functionality may be the same, but the perceived user experience is very, very different.  Context matters, especially when you’re mucking with communities.

And frankly, I find myself disappointed that they claim to be focusing on mailing lists and forums, because that’s not the interesting problem.  I would far rather that they focus on community and identity, which are really the interesting problems that have not yet been well-solved.  Forums are a good use case for those, and it’s possible that they’ll do a lot of good along the way, but I would much rather get a really great, shareable and repurposeable group-management system than just another mailing-list operator.

So we’ll see.  What do you think?  Does this change sound good, bad or indifferent?  Is Google going in the right direction, or are they missing the boat?

Co-editing and conversation

September 29, 2010

I found out today that Microsoft has finally added live co-editing to Word.  In Word 2010, you can have several people working in the same document simultaneously, seeing each other’s edits live as you go.

On the one hand, this is a useful and interesting feature.  I confess, I’d be more impressed if we hadn’t implemented more or less exactly this functionality at one of my earlier startups (Buzzpad) all the way back in 2002; I’m a little distressed by the fact that it’s taken MS this long to catch on.  But be that as it may, it’s still useful.

That said, I suspect that the process is going to turn out to be a bit weak.  (Caveat: I haven’t played with it yet, so I’m going by what the above post says.)  The reason is that they appear to have failed to think about the conversational nature of the interaction.

The thing is, when three of us are co-editing a document, we’re not doing so in isolation.  The co-editing is, usually, an interactive process, where each of us is reviewing each other’s changes, commenting on and tweaking them, and generally bouncing ideas off each other.  Sure, we can each edit in our own little silos, but that’s nowhere near as interesting and useful as a more interactive experience.

So we need to have a conversation as part of this.  As currently constituted, it looks like we need to do that out-of-band.  Microsoft would probably recommend opening up a Messenger conversation for it, and that works, but it’s not a great solution: it loses the document’s context, and the conversation is not itself preserved with the document, so it’s harder to go back later and reconstruct why you made the decisions you did.  As it stands, I suspect that I’ll wind up horribly abusing Word’s comment features to hold in-line conversations.

Moreover, this doesn’t do enough for the asynchronous side of the conversation.  In practice, we’ll usually be editing this document for a while; when I go away and come back, I want to clearly see the changes.  Moreover, I want to see the conversations that led up to those changes, so I can understand them properly.  You can get a bit of this with some of Word’s other features, but it doesn’t look well-integrated.

My guess is that MS decided to finally implement this capability because Wave scared them, and I have to say that I’m disappointed that they didn’t really learn from Wave: this is a comparatively naive-looking version of co-browsing.  The Wave notion, of a root blip (typically the document you’re co-editing) with deep conversations both embedded inside it and attached as later blips, takes the conversational side of co-editing much more seriously.  And the ability to quickly review all changes — both new conversation and edits to the blips — makes asynchronous conversation work pretty nicely.

So points to MS for trying, but it’s still pretty weak.  I hope they’ll keep evolving it in better directions, but I suspect that’ll only happen if the open-source Wave project continues to give them a good fright.

How about you?  Do you think you’d use Word’s new co-editing capability?  Is there anything that would make it better for you?

Wave isn’t as dead as you might think

September 15, 2010

A month or so ago (while I was off on vacation), Google Wave quite publicly failed.  There was much hubbub about that, including my own analysis of what they did wrong.  What has gotten a lot less press is that this is probably the best thing that could have happened to the project.

A couple of weeks ago, Google announced on the Wave Blog that they would be producing “Wave in a Box”.  Basically, they already had made moves towards an open-source version of the server, the FedOne project; however, FedOne was competing with Google’s own product, so it was always a bit second-class.  Now, they’ll be beefing that project up, adding some of the UI power, as well as key features like gadgets and robots, so that the open-source version is at least roughly comparable with what Google themselves had produced, if not as full-featured.

IMO, this is great news — arguably better than if Google had continued the project themselves.  Wave had a lot of problems, but so long as the main implementation was closed-source and controlled tightly by Google it was subject to everything from staffing limitations to Google’s own biases about how things should work.  Now, the open-source version has the potential to let the proverbial thousand flowers bloom — it allows the open-source community to experiment, and figure out what really works in the wild.

Things I’m personally hoping will eventually evolve out of this:

  • External Identity Integration.  This was the biggest single failing of Google Wave, and the biggest roadblock to adoption.  Put frankly, it sucks to have to come up with a separate “Google identity” to use the system.  The open-source version should move aggressively towards a pluggable identity system, with different modules for different needs.  In the wild, it should allow you to authenticate using OpenID or Facebook Connect.  In a corporate environment, it should allow you to integrate using Active Directory.  (The latter alone has the potential to turn this into a far more useful business tool.)
  • Lighter-weight UI.  Google Wave was a very clever idea, but it got way out of hand in its ambitions.  One of the key impediments to adoption was the incredibly complex, sophisticated, slow, bulky client.  Frankly, everything I’ve seen leads me to believe that much of the weight comes from what have proven to be misfeatures: in particular, the customized scrollbar (which is kind of neat, but not obviously better than the scrollbars that the rest of the world uses) and the as-you-type synchronization (which is mildly useful, but which annoys more users than it helps).  So a UI that loses a few of those flashy features, but which loads and runs faster, would be welcomed by most people.
  • IE Support.  Closely related to the above, really — a lighter client would be less demanding on the browser.  I confess, this matters more to me than to most folks, precisely because I want to use Wave in my business, and the simple reality is that most people here use IE.  I don’t expect IE6 support — but having the thing work with IE8 would be a huge plus, and IE9 is almost a no-brainer, now that Internet Explorer is looking to stop sucking so much.
  • Mobile Support.  With everything centered on Google, this was hard.  But if I can create my own Wave site?  Seriously, the first thing I want is a decent mobile client — light-weight, not as full-featured, but enough to let me participate in the conversation from a small screen.  And in principle, there isn’t much preventing me from doing so.
  • A Real Ecosystem.  Google claimed from the beginning that they were trying to create a whole new platform for Internet communications, but shot themselves in the foot by putting themselves too much at the center of it.  With the playing field leveled, that changes dramatically.  There is now real impetus for consistent standards, and a potentially much bigger and more complex market.

Put it all together, and I’m actually excited again.  There are lots of ways it could screw up, but there’s also a real chance that this could start changing expectations about communication.

What am I missing here?  What should folks be doing with an open-sourced version of Wave?  Do you think it has a chance or not?

Wave Postmortem

August 19, 2010

Naturally, I was off on vacation and away from most of the Internet when the news broke that Google was going to cancel Wave As We Know It.  (I love my Android phone, but it’s not really the tool for serious blogging.)  Lots of people have written about the topic, mostly along the lines of, “Wave was always a piece of junk”.  They’re wrong, but the fact is that Google managed to screw this one up in a lot of ways.  Let’s go through some of the problems, and their implications.

Lack of Patience: From what I can tell, Wave has been tossed to and fro based on management whimsy and panic; there doesn’t ever seem to have been a properly designed plan.

It was released very prematurely, when it was barely alpha-grade (and I suspect well before the engineers wanted it released), apparently because they wanted something to show off at Google I/O.  This meant that the development team had to spend the entire past year mostly firefighting, instead of doing the sort of hard and principled sanity-checking and redesign that it needed before public rollout.

And now they’re killing off the public project after scarcely a year: ridiculously too quickly for a product that they had sold as revolutionary.  Twitter is the exception, not the rule: most revolutions take years to percolate before finding mass-market acceptance.  (Think about ICQ, or Friendster, or Mosaic — the first version of a revolutionary idea is usually several years before it hits big.)

I’m coming to the conclusion that Google’s biggest problem right now is that they are being surprisingly clueless about how to manage new products.  Wave is a great product at its core, and Buzz a decent one, but both rollouts have been mismanaged on an epic scale.  If Google needs to fix one thing about the company, this is it.

Identity Integration: Everyone treats this as an afterthought, sometimes even something to be avoided for pure business reasons.  But it’s a huge problem, and Wave demonstrated why.

At initial rollout, Wave didn’t work with any existing identity system, not even Google’s own: you had to get a new “@googlewave.com” address to use it.  Even when they started to open things up, it only worked with Google IDs.

Frankly, this is dumb.  I understand Google’s motives for doing so — it’s technically a hair easier, and it encourages people into Google’s ecosystem — but it’s a foolish hurdle to put in front of a radical new tool that you are trying to get people to use.

The public is suffering a really bad case of identity fatigue: too many incompatible logins to manage.  Each one is a minor thing, but each one leads to an additional reaction of, “What, again?” when folks have to create another one.  In a perfect world, Wave should have been built on a generalized concept of identity that accepted, eg, Facebook logins, but at the very least it should have worked with OpenID and the rest of the open stack.  I remain extremely disappointed that Google put far less thought and effort into this problem than I did on my own for CommYou — you just can’t keep pulling this on the public and expect to win.

Lack of a Killer App: The biggest complaint about Wave has been the constant question, “What is it for?”, and I have to lay a lot of blame at Google’s feet for not answering that more clearly.

The thing is, Wave has multiple killer apps.  It is a brilliant co-editing system, easily the best tool I’ve ever encountered for group document development.  And while it’s a bit overweight, it is in many ways the best conversation tool I’ve found to date (aside from CommYou, of course), mixing realtime and asynchronous conversation smoothly.  In general, it’s a fine collaboration mechanism.

Either of those (and probably other stories) could have been a fine selling point — but Google dropped the ball.  Instead, they simply tossed it out with a vague and confusing “It will replace email!” (what?), and never pushed any motivating examples properly.  So it never developed the core audience that any tool needs in order to survive.

My sometime CTO Chris Herot has occasionally lectured me about the problem of Crossing the Chasm — taking a tool that is great and making it successful.  A key element of that is always the killer app: showing at least one core group of users that they can’t live without this thing.  Google simply assumed that others would do that job for them.  That was arrogant, frankly, and it didn’t work.

Bloated and Slow: Mind, this is a hard problem, and it’s a damned sophisticated tool.  But seriously: Wave runs kind of slowly even on Chrome, and doesn’t run at all on Internet Explorer.  (No, Chrome Frame is not an answer.)

That’s just plain unacceptable for a current web-based tool — again, it was kind of arrogant on Google’s part.  It’s especially unacceptable for a social tool, because social tools are all about critical mass.  If a large fraction of a community is unable to use the tool, that’s an enormous handicap, usually an insuperable one.  And much though Google might wish otherwise, a large fraction of the world is still IE-based.

I can sympathize with Google here, and cutting out IE6 is entirely reasonable at this point.  But not supporting at least the same browser set as Gmail was a serious mistake.  They need to trim down and optimize the UI to the point where it will run acceptably on the full range of modern browsers, if they actually want this stuff to ever be real; anything else is simply wishful thinking.

(The engineers in the audience might want to take note of a general lesson here.  Successful products usually follow the path of starting with a simple tool that implements a great idea, and then slowly expanding from there.  Wave did the opposite: it has a lot of pretty innovative ideas, but has proven to be a bit too ambitious for its own good, putting features ahead of the basics like broad compatibility.  I’d bet that, if you teased Wave apart into its component parts, there are half a dozen great products to be had there, that would be more successful.)

No Mobile Support: Similar to the above, but worth calling out separately, is the fact that there hasn’t yet been any practical way to interact with Wave on a smartphone.  Nowadays, that’s pretty much unacceptable.  I mean, how can you claim to be a replacement for email and not have a mobile solution?

Now let’s be clear: this is hard.  Really hard.  It’s arguably a fundamental design problem — the way Wave works, it really wants both a powerful machine and a big screen, because there is no obvious way to do the co-editing thing without it.

But really — Wave is, as much as anything, a conversation tool, and it is ridiculous that there is no lightweight and easy way to interact with the conversation.  Indeed, if Wave has a killer flaw, this is it.  The conversation mechanism looks and feels great (okay, I’m biased — it’s identical to CommYou), but is fundamentally tied into the co-editing.  A conversation is basically just a document that a bunch of people are co-editing together, and that means that there is no way into the conversation without all that co-editing weight.

This could probably be retro-fitted.  There needs to be a standard robot that monitors your waves and provides a two-way conversational bridge for them, an API for interacting with that, and an Android app that knows your Wave identity and talks to that robot.  A third party could have built that, and still could.  (Indeed, bits and pieces exist.)  But why would they?  This is core functionality, to make Google pieces talk to each other.  Google should have built it and publicized it properly, so that the hardcore members of the Google ecosystem — the sort of people who are mostly likely to use both Wave and Android — could work in a natural way.

Poor Business Support: I’ve spent most of the past year wishing desperately that I could use Wave at work.  Not a week goes past without us getting into some ridiculously nested email conversation with ten participants, where everybody is commenting on each other’s comments, nested five levels deep, using every color of the rainbow to try to distinguish each new set of comments from each other.  It’s idiotically painful, and Wave is precisely the right tool to do this instead: it excels at deep group conversations on a complex topic.

But I’ve been unable to even suggest that we use Wave: there’s no way it would fly.  Let’s get into some reasons why:

  • No SLAs: serious businesses require service-level agreements.  We need to be able to count on a tool that is reliable, and Wave is nothing of the sort.  This isn’t surprising — it was released at alpha-quality, and even today it’s basically a beta.  But it’s no wonder that the business community hasn’t flocked to it, if we can’t take it seriously.
  • No security assurances: I’m an engineer, and I get that nothing online is ever totally secure.  But Google hasn’t been willing to even put a stake in the ground about protecting my intellectual property, even to the degree that Salesforce does.  Without that, there’s no way I can go to my bosses and say that we should hold even casual business-related discussions there.
  • No identity integration: okay, yes — it’s probably hopeless to wish that Google would provide a way to integrate with Active Directory.  But really, it’s a huge issue.  The above problems aside, my IT department is quite reluctant (with good reason) to add a completely parallel user-management system for the company: it’s a recipe for security problems, as well as simply a maintenance headache.

Of course, little of this is unique to Wave: these are common complaints about the Google ecosystem in an enterprise environment.  But it’s particularly acute this time around, because Wave is something new.  No Microsoft-centric shop is likely to use Gmail seriously, since MS is pushing Exchange at you so hard.  But MS has nothing even remotely like Wave, and it is a great business tool, so this would have been a great opportunity for Google to get their foot in the door.  Unfortunately, I think it’s been pretty much flubbed.

Next Steps: okay, so enough about the mistakes.  What comes next?

I’m going to stick my neck out and say: Wave is dead (well, dying); long live Wave.  There are actually a bunch of reasons for optimism.  Google has said that they will be repurposing the technology elsewhere, and that’s appropriate — most of the interesting bits of Wave are infrastructure.  I’ve argued for months that combining Wave’s conversational strength with a social network (eg, Buzz) would produce the first serious competitor to the LiveJournal platform.  So I hope that Google is smart about that: that they are finally getting serious about the crossing-the-chasm problem by integrating the Wave technology inside real apps.

On the downside, if they don’t replace the Wave Inbox in some smart way, that’ll hurt.  Inbox is one of Wave’s quiet strengths: a concise and very effective way to catch up on what’s been going on, whether you’ve been off having dinner or on vacation for weeks.  I do worry that, if Google uses the Wave infrastructure without providing Inbox or something like it, the system will lose half its usefulness.

Also, there’s probably a bit of brand poisoning here.  Frankly, Google handled this a bit clumsily: by killing off the main Wave project so publicly, I think they’re going to associate the whole thing in the public mind as a failure.  That would be a damned shame, since so many of the individual pieces are so right: the failure has been mostly a management one at Google, failing to put it all together correctly.

But the underlying Wave protocol is open, and I think is here to stay.  Competitors like Novell are already adopting it, as are open-source projects using Wave.  I hope that projects like the Wave Forum (an open-source effort I’m helping with, to build a truly great forum system on top of Wave) will simply change gears a bit and move forward whether Google is pushing things or not.

So: opinions?  Counter-arguments?  What are the problems that I’ve missed above?  What pieces of Wave do you think can and should be pulled out and reused?


Follow

Get every new post delivered to your Inbox.

Join 363 other followers