Do you know finger, talk, write, who, etc.? You could if you had gotten in contact with unixoid computing systems. With the concept of client and server, multi users, sharing resources, connected systems, and collaboration were part of the system. Those only things everyone knows from this (ancient) world are the hypertext system called world wide web and emailing.
While with the introduction of the personal computer (PC) and it’s dumb operating system (DOS) those programs did not make it into everybodies computing experience, the concepts behind are now having their reincarnations, thanks to the internet. People are turning their personal computer into (fat) clients for servers on the internet. They register an account in the service system and start to cooperate with the other users in the system. E.g. chat and presence systems like ICQ etc.
There is not one system, but several, incompatible. In protocol, services, and account data. This is good for protection against too easy monitoring by third parties, but inconvenient also for an innocent user. She needs to know all different accounts of her friend and map them all into one data set in her mind/local addressbook. One for the email system, one for the chat system, one for the file system, one for the phone system, one for the postal system, and so on. Sometimes even more than one for a system. Alright, we are used to that for ages, thanks to the postal and phone system. But we are not used to the boost of the new service types, with new address types and entries. Where in the addressbook mask shall the user add the image gallery account of her friend? Where the feed address of the video blog? How to support these systems and their possibilites from all programs? And what to do if the support for systems is switched, like Olivier Goffart proposes?
Obvious solution (for me): Support for specific systems should not be hardcoded in contact managing/using programs. I found out about this when coding a contacts menu for kicker. Instead all the different systems need to be supported by plugins. Plugins, which deliver components for the display of the system specific address type, for the display of the status within the system, for the editing of the address, for the action services, and perhaps more. Adding some MVC to the recept, and the programs are quickly adapted to new systems, given a specific plugin for it.
So a contact card view like the following would display a set of strings and icons, without knowing about the addresses and states behind. The controller would, in reaction to LMB and RMB clicks on the entries, perhaps show the services’ display strings in the menus and call them based on id strings, without knowing what they really cause:
Another view could be a contact icon, which sits on Kicker, shows icons of the current state within the systems with an account for, and offers all available services, e.g. for a drop of several files, like this:
How much code there is behind these claimed-to-be mockups? Well, investigate yourself… 😛