The Hidden Danger of Gmail Labs

June 6, 2008, 2:58 pm By Saul Hansell

http://bits.blogs.nytimes.com/2008/06/06/the-hidden-danger-of-gmail-labs/

Two of Silicon Valley’s truisms are increasingly in conflict with each other, and you can see the battle at Google.

The first is that to make software that is really powerful and easy to use, you take out all but the most essential features. Apple has been the leading advocate of this method. Google, too, has often, but not entirely consistently, tried to introduce products where the complexity is under the hood, not in the screens that users see.

The second very popular idea, competing with the first, is that software and Web sites can be made far more useful if they are opened up to additions and modifications from others. Firefox browser plug-ins and Facebook social networking applications are two examples of this approach.

The conflict is obvious. A community of developers can enrich software with creativity, fun and all sorts of utility. But it is virtually impossible for a mob to keep it simple.
That is the challenge raised by the latest experiment from Google: Gmail Labs. It’s a new program that lets the company’s overflowing cadre of engineers design new features for Gmail and expose them to the public.

I first skipped past the frenzy of coverage in the Valley about these relatively minor tweaks, but upon reflection, I think there is a potentially dark side to all this fun.

Here’s how Keith Coleman, Gmail’s product manager, described the idea in his blog post:

The idea behind Labs is that any engineer can go to lunch, come up with a cool idea, code it up, and ship it as a Labs feature. To tens of millions of users. No design reviews, no product analysis, and to be honest, not that much testing. Some of the Labs features will occasionally break. (There’s an escape hatch.)

The first crop includes 13 features. Some of them are handy tweaks, like the option to change how your signature is formatted. Others are goofy, like a game that has a digital snake crawling over the e-mail screen.
In one sense, all this silliness doesn’t affect the simplicity of the main Gmail program. Users won’t see any of these new features unless they enable them in a new “Labs” tab on Gmail’s “Settings” page.

Still, this program formalizes and makes visible the war between more features and ease-of-use. If a Gmail Labs feature becomes popular, at least with a small set of early testers, there may be pressure to promote it to the main program.

All this might be for the good. Each year that goes by, a greater percentage of the population is of the generation that grew up with a mouse in the cradle, and thus the demand for more power and flexibility from software rises and the need for simplicity may lessen. And we see every day how much value is created when the power to create is spread widely.

But any creative process alternates between tightness and looseness, between brainstorming and prioritizing. And I think that Google’s ever-expanding array of services already suffers from the ills of too many different authors. While most of its products have relatively spare interfaces, the products differ as to how they work and, taken together, are harder to use than they should be. Consider, for example, all the overlapping and not entirely integrated ways that Google users can take advantage of feeds and gadgets: iGoogle, Google Desktop, Gmail, Google Reader, OpenSocial in Orkut and so on.

I’m not saying any of this experimentation is wrongheaded. But once the experiments are tried, someone needs to shape what has been learned into software that gives the most power for the least amount of effort.

I’m not sure how many Google engineers want to use the precious time allocated to their project to consider what features to cut. But the question Google, Facebook, and Mozilla have not finished answering is how the power of open can be balanced with the simplicity of closed.