User innovation toolkits and continuous improvement

Discussions of software as a service tend to focus on its obvious benefits: zero-footprint deployment and seamless incremental upgrades. Less noticed, but equally valuable, is the constant flow of interaction data. The back-and-forth chatter between an application and its host environment can be a drag when connectivity is marginal and it precludes offline use. But when this communication flows freely, it paints a moving picture that shows how individuals and groups are using the software. As they watch that movie, developers become intimate observers of their users. They can't help but think of ways to optimize the patterns they discover, and, as a result, the software improves gradually and continuously. [Full story at]

This week's column explores the kinds of interaction data produced by a range of application styles, from Web 1.0 to AJAX to demand-loaded rich client to full-on GUI. As you move along this continuum, the availability and nature of this data varies in quite complex ways. The general point is that, whatever the application style, the more you can find out about how people are using software, the better.

The corollary I forgot to mention is that the more you can find out about how people are modifying your software, the better. Case in point: my latest Greasemonkey-based Gmail tweak. After tire-kicking Zimbra I started thinking about ways that Gmail could be doing more with the information it has. Why, for example, only link items in the inbox to the message viewer? Why not link each item's contacts to something more useful, like the histories of prior communication with those contacts?

I came up with a partial solution which I'll share, with some caveats. I haven't yet automated the transfer of data from Gmail's contact viewer into the script, the linking doesn't work in all contexts, and I can only open the contact histories into new tabs, not the current window. But it's a decent start, and useful to me as is. If you carry the ball further, blog with a link back to this entry and I'll find out about it.

When running Gmail with this script enabled, I noticed an unexpected benefit. The names of contacts are links, but the names of non-contacts aren't. Now for the first time the two classes are visually distinct. I know at a glance who's in the address book, and can make better decisions about whom I'd like to add to it.

This is a nice example of what Michael Tiemann, in his talk at the MySQL Users Conference, called user innovation toolkits. The idea, Tiemann said, comes from Eric von Hippel, who wrote:

User innovation networks have a great advantage over the manufacturer-centric innovation development systems that have been the mainstay of commerce for hundreds of years: they enable each using entity, whether an individual or a corporation, to develop exactly what it wants rather than being restricted to available marketplace choices or relying on a specific manufacturer to act as its (often very imperfect) agent. Moreover, individual users do not have to develop everything they need on their own: they can benefit from innovations developed by others and freely shared within and beyond the user network. [Eric von Hippel: Open source software projects as user innovation networks]
That article is about open source software, but von Hippel applies the same principles to innovation in manufacturing -- notably in the case of GE Plastics which, according to von Hippel, figured out how to move the locus of design from itself to its customers. Tiemann adds:
One of Eric von Hippel's punch lines is that 85% of all interesting innovations in all industries come not from the suppliers but from the users. What rational person today would give up the opportunity to do the vast majority of their innovation by restricting their users from accessing and becoming part of the design cycle?

I don't know if my latest Gmail tweak will catch on but, if it does, the patterns of interaction with Google's servers will vary in ways that Google will be able to analyze and react to. Web-style software isn't the only way to establish this kind of tight feedback loop, but it happens most naturally in that context. Rich clients can -- and I argue should -- figure out how to tap into this process too.

Former URL: