Anyone remembers this? Before .Net, before ActiveX, before COM there was OLE, the way that various software products could communicate one with another. The idea was that a software product would delegate various tasks to another product which was better equiped for it.
I remembered it a few months ago when I went to a head-hunting agency and I watched the secretary punching in my information. She was jumping from Word to Excel, back to Word, back to a different Excel file, etc… Very, very ineffiecient. I could not help having the feeling that she was actually taking on the role of a software program, that all the repetitive jumping from one file to another could have been analyzed as a business process (it is a business process after all), abstracted and implemented.
Back in the days when desktop computing ruled one way to implement this business process would have been by using OLE. You would have basically created a shrinkwrapped product (anyone remembers this one too?) that would have delegated thru OLE various tasks to products that did them best: Word would have taken care of CV editing , Excel would have taken care of managing the client information, Access would have managed the CV repository, etc… Your product would have concerned itself with the management of the tasks of a head-hunting agency. Your product would basically take different existing software products and put them together in a meaningful way, effectively implementing a business process. This approach would have been better than creating proprietary software for all the parties: the developer would not have had to be concerned with creating a good text editor and the customer would not have had to retrain its staff because they were already familiar with the various pieces that make up the product. If your product was well designed it could have been able to plug different products (let’s say different word processors) in your business process so that the secretary would continue to use WordPerfect instead of Word if she was proficient in it. Your software product would have been tailored to your customer and its business process.
Unfortunately, this type of desktop mashup never occured. More and more proprietary software was churned out at great costs for everybody involved. Small customers continued the mundane practice of copy and paste (in some cases to this day) while big customers shelled out big bucks for `solutions` which were sent to the recycle bin the moment the web revolution took place.
Hopefully, the current `mashup` mindset will put an end to developing huge elephants and make developers concentrate on processes rather than on infrastructure. Anyway, it is more fun.

I was thinking about the “Keep It Short and Simple” mantra applied to UI for desktop products and I was wondering how you could build a large desktop application and have your users manage a large array of components very different in functionality one from another. I was thinking mostly about applications such as Netscape 7 (anyone using it anymore?) where the user has to choose between a large number of components: stock quotes client, email client, RSS feeds client, AIM and whatever other AOL software is bundled in Netscape.
So far the approach for managing large number of components was to basically swamp the user in an ocean of checkboxes, radio buttons, dropdowns, etc… which they would have to click in order to get to the component that they need. Microsoft Word is the perfect example of it: at an UI work-shop I saw Word with all its menus expanded and the text area was shrunk down to the dimensions of a stamp. This approach obviously doesn’t scale: there is only so much room on your user’s computer screen and the user’s attention span and patience can stretch only so much.
A far better approach would be to have the user discover what it needs from what you have to offer and make the management of those components easy for the user. I am thinking that a product should have a component search capability that would let the user search for its components. A component registry with search capabilities would probably solve this. Also, the user could tag various components and search components tags in order to find what it needs. Basically, every known form of collecting and searching for information should be used for letting your user manage the components easily. Whether collecting and querying this information is done locally or remotely is, obviously, particular to the application being developed and its operational environment.
The big number of components that your application would have to manage would imply that your application should exhibit a certain degree of plugability: the application’s components should interact with one another seamlessly and should be set-up very quickly. Various plugability contracts should be set-up: a component should be able to be demo-ed (without a demo a user would not be able to decide quickly if it needs the component or not), installed, un-installed, re-installed, loaded into the application at runtime, discarded/hidden at runtime, etc…
The product would then become a platform on which various plugins are set-up and assembled together, very similar to the Eclipse IDE. This leads me to say the following: one way to see how the interaction between different UI components will be implemented in the future would be to check out Eclipse’s source code. Eclipse has a certain level of UI plugability and it has the lowest barrier of entry for a developer: it is open-source.
Hey, if your UI requirements match Eclipse’s plug-and-play skeleton you could even use its skeleton for your application (*). The skeleton of the Eclipse IDE would become the free or low-cost infrastructure that you would use for setting up your application.

P.S. Along with the Web 2.0 buzz some sort of a revival in UI is taking place. It looks like interacting with users is being thought about again. Martin Fowler’s GUI Architectures is worth checking out.
P.P.S. When writing this I kept thinking about the launch of Google Talk and the spartan user interface it had at the time. I was wondering how would an user of this product find its various services if the interface was kept simple.
P3.S. This article is concerned with UI management on desktop applications. I think these UI management requirements apply to web-based products but the implementation would be very different. A web application would be transformed into a portal that is easily to be managed by the user. For example, I would like to go to Yahoo’s page and have in the upper right corner some stock quotes, next to them press releases or news about those stocks and in the middle of the page general news. When I’m planning my vacation I would like the middle of the page to be a list of various trip packages rather that the news I usually have. I would like to put up these components and shut them down very easily.

* As far as I know Eclipse’s plug-and-play architecture is intrusive, you have to implement various interfaces, etc… Using Eclipse as a skeleton for building desktop apps would couple your application strongly to Eclipse unless you abstract the interaction between your UI components and create a bridge which will be used for having Eclipse boot-strap your application’s UI. This way you could use other plugable UI frameworks, such as Firefox, for assembling your application’s UI.