web style software

I imagine that web style software will diverge into two general groups:

Domain Specific
Domain specific software will export their functionality through a web api. They may or may not also provide implementations of these api in several languages. It’s quite common for vendors to release bindings of their library in a choice of C, python, perl, php, C++, ruby, javascript et cetera… The same will still be so, however these kinds of services will focus on providing functionality for a class of objects (or domain of data types) that it specializes in. I happen to be using one right now: wordpress. Some other examples of domain specific web style software include google, yahoo, delicious, evdb, et cetera…. The publishers of these apis also happen to choose to provide a human interface to their data. These publishers also realize that other people may be able to integrate not only the kind of data they specialize in, but the very expertise in these matters into a new medium in a way that benefits everyone.

First of all, the network effect teaches us that the more a service in consumed, the greater its value. By exporting data through a web api, web style software publishers make it possible for anyone in the world to increase the value of their service. This principle is what makes Google so successful. They realized that by making venues where millions of people consume information, that their network would be valuable. The way they capiltalize on their system’s value is by selling spaces for ads on not only their sites, but many participating sites as well. In addition, google exports many of their product features through a web api. Some examples are the map and search api. This allows third party publishers (the group I’ll discuss in the other class of web style software publishing styles) to take advantage of google’s expertise in search and maps on their own site. This increased consumption firmly roots a dependency in the marketplace satisfied by google and by the same token increases the value of Google itself.

Domain Agnostic
These are resources and services that consume web apis that are domain specialists. These may be things like tiddlywiki, or grease monkey scripts, python programs, web portals, things like the tabulator. Browser architecture has been made modular so that third party developers can extend and enhance the functionality of a browser swiftly. This facilitates end user consumption in new and unpredictable ways.

This may sound like a user interface problem; something that we’ll figure out in a few years. However, the way we expect to interact with the world around us doesn’t quite mesh with the way computers operate. This mismatch will leave room for improvement in human-computer interactions until selective forces pressure us to deal with virtual spaces better.

With the vacuum of the perfect interface will make room for many many services providing dynamic interfaces to domain specific data in a generalized way. It’s not too hard to imagine that this class of web style software may in turn be cannabalized and consumed by subsequent next-generation software. TODO: Is this one of the design goals of xforms? xul?

Personally, I find human-computer interaction way more fascinating. I’m no usability expert, but it’s a topic I’m very interested in. I’m currently focusing on a framework to easily publish the domain specific web api’s, so that I can get around to building the generalized browsers.


One Comment

  1. Posted January 12, 2007 at 3:01 pm | Permalink

    I am just amazed at how well you write! Keep-on going you are just so good… mary

Post a Comment

Required fields are marked *

%d bloggers like this: