updates @ m.blog

Between Services and Interfaces

Recently, Matt McAlister made reference to a tangential conversation we had about interface and utility during a meeting about user interaction models. It’s something I’ve been thinking quite a bit about over the past year, so I figure its worth a bit more discussion. What I really see coming about on the WWW is a distinction and separation between services and interfaces.

For example, look at Gmail.com, as an example of a provider of both of those. The service component of Gmail is the 2GB of mail storage, the @gmail.com email address, the spam filtering, etc. The interface is the rich-client AJAX website users interact with directly. Gmail is typical of most user-centric websites—from the user’s perspective, the two are tightly linked.

On the other hand, a site like del.icio.us is pretty squarely in the pure service model. Sure, it has a web interface, but that interface is utterly non-compelling—what makes the del.icio.us service valuable is integration into other interface tools—Firefox RSS bookmark folders (or Flock) for example.

What we haven’t seen much of (yet) are websites providing pure interface. RSS aggregators would be one prominent example, providing an interface to existing services (they do have some service components in the crawling and aggregation service—however it’s fairly easy to imagine a pure reader application that takes a pre-aggregated single RSS feed.

But why not make a Gmail interface for people who don’t want the gmail.com service? Personally, I already have plenty of email addresses, storage, and filtering on my own mail server. If either Gmail or Yahoo! Mail Beta were to provide IMAP capabilities into their client, I could utilize it as a web interface to my existing mail service. (Why don’t they do this? Lock-in. If they allow their service and interface to be disconnected, the transaction costs of switching for a user are very low–making it easy for users to try out new things without losing their existing data. The problem with an “all-or-nothing” approach is that sometimes, users—like me—will choose the “nothing” option. While they’re not going to switch me from being a Thunderbird user at home, if they had an IMAP interface, either Gmail or Y!Mail would get the “something” of being my access mediator when I’m at a public internet terminal with only web access–and they could happily push advertisements to me at that time. In the web market, there is increasing value in being the middle-man.)

Long term, what I’d personally love to see is a complete decoupling of services and interfaces, and an easy to way to shoot stuff between multiple sources and interfaces. Imagine the power and simplicity of pipes on the Unix command line, but with decentralized web services. When am I going to be able to do:

cat bloglines_aggregator.com | url_extract.yahoo.com | sort.google.com | uniq.google.com | pattern-matcher.com?f=mroth > del.icio.us/post/mroth

without writing a single line of API interaction code myself?