This is the first of a two part series.
Information overload is a condition that many, if not most users face on a daily basis. Email, phone calls, instant messages; this list is endless. While end users are generally not very skilled in bit literacy, developers shoulder much of the blame and it is up to the developer to make sure that their applications and devices actually help the user, not hinder the user. In this initial part of my "Information Overload" series, I will show some examples of how developers can help resolve this problem.
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.
The easiest way to "deal" with this problem is to simply ignore it. It seems like every developer imagines that their application will become the users' new "home" throughout the day. This is an example of "developer hubris." Chances are, your user will not "live" in your application. In reality, your users have Outlook (or some equivalent) open all day long, and an IM application or too. The last thing your users need is yet one more application sitting in the system tray, popping up "piece of toast" every thirty seconds demanding attention or notifying them of a new message. On the other hand, you do not want them to only check your application once every few hours to see if they need to do anything in it.
The best way to resolve this problem is to acknowledge that your software is probably not the most important thing in the users' lives, and to work with their existing systems. Instead of delivering messages and notifications to your own data store, why not deliver it to Outlook? If the users do not use Outlook, send the messages via RSS or email. This way, the users do not need to monitor yet one more application. In addition, the users are already familiar with their existing applications, and can use that application to organize your information in the manner that suits them best. Another advantage is that it is actually less work to do this for you. If you have to choose between reinventing the wheel (data storage, searching, organizational capabilities, filtering, etc.) and simply working to deliver the information via a standard delivery mechanism, which would you rather do?
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.
This is really the same problem as the "Too Many Inboxes" issue, just in reverse. Why not offer the users a way to communicate from their existing application, using your application as a pass through? For example, a document management (or online content management system) that presents itself as a Word plug-in is a heck of a lot easier for a user to use regularly than a system where the user needs to take active action. A system that lets a user work with it from within Outlook to perform online scheduling (or send an email to a special email address) is going to get a lot more use than something that lives in its own space.
The vast majority of the overwhelmed are using Microsoft Office. Modern versions of Office are capable of being pluged-into via COM. The .Net Framework makes it extremely easy and attractive to target an Office application as the wrapper for your code. There is a reason why so many users use Excel and Word to do things that they "shouldn't" do; these applications are familiar and comfortable to them. Instead of writing yet another application that gets dusty and grows mold through disuse, why not leverage the users' existing comfort zones and knowledge base and work within Office?
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 Microsoft 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.
Passport seems to involve giving Microsoft money, and who knows what the case is with Liberty Alliance? One alternative is to leverage the users' existing authentication scheme, whether it be LDAP, Active Directory, or something else. The Higgins Trust Framework seems like a great idea as well (essentially on open source version of Passport or Liberty Alliance), and I truly hope it goes somewhere. Unfortunately, most services will not let you authenticate against their servers, at least not the common ones. For example, Yahoo! will not let you authenticate against a Yahoo! ID without some sort of partnership. I think this is a real shame. Most people have a Hotmail or Yahoo! username (Google is pushing their users to get Google IDs as well, but their market penetration is startlingly low in non-search market segments).
However, systems designed for internal usage have no excuse whatsoever. If you are writing a client/server application, you should not ever need to ask for the user to authenticate, unless they need to escalate their login to a more privileged level. Except in a few very rare occasions, the fact that a user is logged into their desktop should be good enough for your application. Reduce the logins, and increase the happiness.
Justin James is the Lead Architect for Conigent.