In my last post, I kind of dumped a lot of ideas that aren't necessarily as obviously related as I had initially thought. With that in mind, I'm going to have seperate posts to describe many of the issuses in the hope that the relation will become evident.

I'm going to start with what I think is the most important issue behind a revolutionary change in development enviornment. That is specifically the idea of replacing applications with services that provide the essential functions of the applications in a way that the user is able to build an interface around them. Again, my example is XMMS2, where playback and media managment are handled by a service for which various interfaces (or clients) can be made. This means that interfaces can be made for the exact task at hand (I don't need a media library browser to pause my music.) This concept is exactly the direction I think development of the computer interface should go in because it assumes from the begining the basic thesis that, users have personal preferences, and certain interfaces are better suited to certain tasks. This means that much more lightweight interfaces can be used generally, with the ability to pull out something more heavy weight if it's required. It also means that if you have a bunch of services, by their very architecture they can interact with each other.

The service-oriented interface would be unfamilar. The ability to build interfaces for each task would be a common process, indeed the interface building interface, which would allows for connecting various services and visual or textual components together, would be the center point of the user experience. Being fully aware that many tasks are going to require similar interfaces, the ability to save prebuilt interfaces and to draw from a library of already implemented interfaces would be trivial. While the interface building interface would be central, a necessary feature of each service would be a relativly accessible interface for most level of programmer. Direct programming of interfaces should not be hidden nor required, and should provide a welcoming enviornment to those who wish to learn about building interfaces without the interface building interface. Access to the services should be available to as many languages as possible so that those that can already program will be able to comfortably work with the services. It's a mistake to pigeonhole the services to one toolkit, framework, or language. That defeats the purpose of the service-design which is to try as much as possible to allow user's personal preferences to be possible.

While the interface building interface is a bit of a pipe-dream, services are not. Their design makes it possible to use them in nearly any situation. With that in mind, I've begun to write a mail service (which currently indexes headers from my mailboxes.) The mail service will ultimately provide the ability to send mail, as well as retrieve mail from remote and local mailboxes indexing headers from that mail and providing the ability to search, organize and read mails as well as be notified of changes to mailboxes. Basically all the functionality needed for an MUA. The mail service will be the first (or second, if xmms2 is included) of many services that will make a new computer interface possible.

Hopefully decopuling services as a concept from metadata and organization as a concept will make it more clear what exactly I'm trying to achieve. I'd really like to spurn further discussion on this topic so, use comments, email me directly, start writing your own services, help me out on the mail service, get involved with xmms2, or tell me I'm insane.