1 August 2006 - 14:34Interacting with users

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.