This is the introduction to a two part series.

Bill Gates recently wrote about the overload of information that people face in one of Microsoft’s June 27th 2006 Executive Email (“Bill Gates on the Unified Communications Revolution“). What Mr. Gates understands, and most developers do not seem to understand, is that the proliferation of various electronic communications methods, while resulting in an increase of speed of communications, has a point of declining returns to the point where productivity is harmed. Part of the problem is on the users’ lack of bit literacy. And much larger share of the blame falls on the shoulders of programmers and companies putting out software and devices which refuse to interact with anything else. While there are legitimate technical and business reasons for creating these isolated devices and systems, the solutions end up only addressing the users’ how and rarely their why.

This series of articles will examine the different types of information overload, and what developers can do to address the problems.

PART 1 – Too Many Options

Too Many “Inboxes”

Users receive messages through a ton of different methods. To make matters worse, many of these methods require manual intervention. Once data is on the wire, it should find its way to the best destination based upon the receiver’s preferences and availability. For example, if I am away from my desk, email should come to my cell phone (and automatically synced with my desktop mail client) and MSN or Skype VoIP contact attempts should ring my cell phone. Once I return to my desk, they should come to my desktop, and through a central piece of software. The average user now is running an email program, checking Webmail periodically, has multiple email clients, three or four phone numbers, and even more inboxes, when they really just need one.

Too Many Outboxes

There are far too many ways to communicate with people. For most of the people in my network, I have the option of using the phone, IM, and email. Some users add in various Web forums, walled garden outboxes, faxes, and even more ways of sending a message. What users really need and want is one method of sending voice, text, and data from their desk, and another way of doing it mobile, with the best outbound path being chosen based upon availability of the data path and the receiver’s online status.

Too Many Sign-ons

We all have way too many logins to manage. Over the course of a day, most people have three voicemail passwords (home, work, and cell phones), 2 or more IM usernames, a webmail username for personal email, a work login (and way too many companies have different logins for each system as opposed to just all using the same username/password database), and so on and so on. It is simply unmanageable. A number of years ago, Microsoft pushed Passport, and ABM pushed the Liberty Alliance. The only place I see Passport is on Micrsoft properties, and I do not even know who uses Liberty Alliance. Because of username/password overload, users do not access all of the routes that belong to them.

PART 2 – Data Difficulties

Walled Gardens

Far too many content and communications systems are walled gardens. What this means is that while working within the system is great, it has no way of communicating with the outside world. MySpace is the biggest example of this. The blogs you post there cannot be accessed via RSS, the songs, videos, and images you post cannot be accessed outside of their system through URLs, and you are unable to send messages outside (or into) MySpace. In a nutshell, it is like having a cell phone that is unable to call any phone except other cell phones with that provider. What this does is force users to spend far too much time accessing and using far too many devices and systems in order to work with everyone in their network.

Lack of Storage Unification

Even for systems that are not walled gardens, there is a complete lack of storage unification. For example, a message sent through Yahoo! Mail does not appear in my Outlook “Sent Items” folder. A file stored in Flikr is completely cut off from my local file system; a change in one requires manual intervention on the other. As a result, users end up with a large number of places for data to be stored and hidden. Users need less storage areas, not more, that seamlessly sync and interact with each other. Even more importantly, simple data such as basic word processor documents need an easy way to appear on Web sites.

The Metadata Problem

Metadata is great. Not only does it provide useful information, but it is a great aid in the data searching process. Unfortunately, very few systems automatically generate metadata. While they offer systems for the manual creation of metadata, rare indeed is the user who tags, marks up, or enters metadata. More systems need to find ways of properly providing the metadata automagically.

Poor Search and Lookup

Most search systems offer simple text search, and sometimes allow the user to refine their search based upon metadata. This is just not enough. For example, if you remember that someone emailed you their phone number, which is better? Searching for all emails from that user, or being able to use a pre-defined regular expression (such as “find all emails from John that contain a phone number”)? More systems need to support regular expressions in a way that the average user can understand, and pre-define appropriate searches. In addition, more systems need to search through automagically generated metadata.

Data Format Chaos

Right now, all of our data is in far too many formats. Format incompatibility and conflicts are the kinds of issues that users simply do not care about, only vendors. The user does not care if they are using ODF or OpenXML, they only notice the format if it gives them a problem. Documents need to be able to be seamlessly shifted to the Web or from the Web to an environment where they can be edited. Vendors need to learn that the value they add to the users does not come from a file format, but comes from their business logic. Furthermore, as code increasingly gets developed within managed code with massive standard libraries (Java, .Net) or uses common open source libraries, the urge to develop custom file formats is reduced.