 |
version seven. http://demongin.org |
Here's What's Really Wrong with Google Buzz
Or, alternately, "HI BUZZ LOL".
Thursday, 2010-02-18 | On the Internet
| This is a significant breach of consumers' expectations of privacy. Google should not be allowed to push users' personal information into a social network they never requested. |
| Marc Rotenberg, EPIC executive director. |
I've been repeating myself a lot lately about Google's Buzz.
And, usually, when I find myself saying something more than once to more than one person, I make an effort to write it down, so I can have a few one-liners and canned arguments to toss around if it comes up again. There's something about working things out "on the page" that catalyzes the opinion-forming processes and helps lodge phrases in the memory: writing is the violent sublimation of the ephemeral to the historical, after all, and what is history if not a collection of only the most memorable tenable and untenable opinions?
So let me begin my essay on Google Buzz by saying this: though I have been outspoken in my condemnations of the thing, I believe that much of the criticism of Buzz is unjustified and inappropriate. I don't know about you, but I have noticed that the lion's share of the criticism that the service has drawn since its launch seems to take the form of feature requests and bug reports: most "critics" of the service write about how they want this or that functionality, or they detail this or that problem with the application, but very few of the writers I've come across say anything meaningful about it. Problems with the Buzz UI, when brought up for their own sake, say nothing relevant or important about the service.
If you're alive and you've got an Internet connection, you know by now that practically everyone, from eminently credentialed LifeHacker alum and Google expert Gina Trapani to the official mouthpieces for the Big G itself, has come out against a lot of the application-level flaws in Buzz.
And though doing-so is tedious, application-level criticism is an important piece of the puzzle, and any serious essay about Buzz is bound to account for it. Additionally, application-level criticism of the service frames the larger point I intend to make about Buzz. And so, in order to not belabor points that have definitely been belabored elsewhere, I'll gloss the major problems with the Buzz launch in a few bullets:
- Google made a hash of privacy controls (and is apparently facing a class action lawsuit for having done so). In addition to subscribing users to a service without their knowledge or consent, personal and protected names and contact info were shared inadvertently and at random in an uncontrollable manner.
- Following/follower logic was remarkably poorly conceived. Any networking service that exposes users to broadcasts from other users whose feed they did not explicitly agree to monitor has failed; "opt-in" is what makes things like RSS and Twitter great--forcing users to "opt-out" is simply an objectively wrong approach that misunderstands some pretty fundamental elements of Web2.0.
- Spamming users gmail inboxes with updates re: responses to their Buzz posts is unforgivably stupid for obvious reasons: this should have been nipped from the "features" list waaaaaaay early development.
- The manner in which other services "plug in" to Buzz was also poorly designed/conceived. Numerous commentators have noticed that Buzz is an unapologetic shot across Facebook's bow (or, if not an attempt to scare Facebook out of the email business, it's at least an attempt to start getting time-on-site numbers as high as the ones that Facebook supposedly enjoys), but repeating Facebook/Twitter/etc. posts and updates is, as far as the average early adopter is concerned, nothing but a nuisance. Even down the line, my feeling is that people will continue to want to keep these feeds segregated, interacting with Twitter on their phones, Facebook in their cubicles, etc.
There's simply nothing there.
Google Buzz is a software designed by people who were very clearly thinking/planning/acting from a business perspective in order to accomplish a business goal: Buzz will never be useful as a communication or information tool because it was never intended to solve any existing communication problem or bridge a gap in any existing information system in the first place.
Which is why I regard a lot of the application-level "criticisms" of the service as irrelevant but simultaneously important in framing the issue: complaints about a broken or missing feature (e.g. the common gripe about privacy or the annoying manner in which other tools such as Twitter are integrated), implicitly make the point that Buzz is nothing more than a me-too application that currently suffers from bad feature-creep and ultimately has no "win condition" or "exit strategy". No one asks about what this thing does or why it does it or the best way to do it, because the answers to those questions are self-evident: Buzz doesn't do anything and therefore it needs to be "gated" or otherwise prevented from doing things that other things already do.
Which, as I mentioned above, is why so few of the complaints one hears about the UI are relevant to service. Most of them are aimed at limiting its functionality but don't explicitly make the point that the best thing you can hope for in a situation like this is to prevent the thing from running amok. It seems unavoiable, if you only consider the UI, that Buzz doesn't do anything and that no one wants it to do anything. If you consider that the UI is designed to help users control the thing, the whole design begins to seem inherently self-defeating.
But, to be fair, to come to that conclusion is to have neglected several important details.
It is important to remember that Buzz aggregates and collates ephemeral conversations (not unlike ThinkTank and other less personalized Web2.0 aggregators that parse social networking feeds). Someday, its various indexes and cross-references could potentially be used to help individual users get better Google search results based on who they know (or who and what those people know, etc.).
Buzz is, of course, self-defeating in this regard as well, as it essentially encourages users to cast hay onto an already towering haystack of information with the expectation that the occasional user will toss in the occasional needle (or that the occasional user will bridge a gap between what would otherwise be two unassociated pieces of data).
Lots of noise. Minimal signal.
And, it can't be forgotten, that signal-to-noise problem in Buzz's design and potential future-application is replicated in its user interface. Assuming that every single one of the application-level quirks/bugs of Buzz were fixed as well as they possibly could be fixed, the idea of a public-facing status-update aggregator attached to one's email box is still a fundamentally bad one from an application-level perspective, as it duplicates and indexes ephemeral conversations needlessly (as in the case of re-posting tweets), exposes non-ephemeral communication unnecessarily and potentially subjects users to broadcast messages they never agreed to see. There's a ton of noise here too, and even where signal gets through, users might just end up wishing that it hadn't.
And, while we're on the subject of design flaws that are manifested int he UI, let us also not forget that it was noticed and remarked upon widely and almost immediately that Google Buzz seemed to be a less work-oriented (i.e. more play-oriented) version of Wave (i.e. a less obfuscatory, feature-rich version of the widely panned collaboration tool).
Since then, that opinion has coalesced into an equally widespread speculation that as Buzz continues to grow and develop, it will come to be a sort of Wave-lite: all of the media-embedding and gimicky, Web2.0 stuff from Wave will be a part of Buzz, but none of the editing, publishing or other results-oriented features will be included. And this speculation, which seems fait acompli after week and a half of Buzz, is probably correct.
More's the pity, because here, as before, we see that Buzz, as a consequence of poor design choices that must necessarily be reflected in poor implementation strategies, will most likely end up being a service that intentionally lacks the features that make Wave attractive to long-distance collaborators and which sacrifices the design and feed minimalism hard-wired into Twitter. Which, again, points to the conclusion that Buzz is a weak application based on a bad idea with inherent limits on its potential that demonstrate profound shortsightedness and a lack of circumspection.
Which is, I hardly need to point out, exactly the sort of thing that happens when the MBA's start calling the shots in the project management and product development meetings.
