Ben Collins-Sussman
December 18, 2004
(I state this explicitly just in case anyone is looking for prior-art proof of these ideas.)
Back in the 1980's, operating systems were nothing more than commandline UIs used to manage files. When somebody sat down to work on a particular task, the flow of thoughts often looked like this:
|
I'm working on task or project X.
|
In other words, life revolved around launching giant single-tasking applications. Because most folks were lazy, all of the documents created by an application often ended up being saved in the same folder as the application itself!
Along came the Mac GUI, which finally spread to the masses in the 1990's via MS Windows, and then everything changed. The underlying system had a concept of automatically associating certain documents with certain applications. After the paradigm shift, a typical user's work pattern changed quite a bit:
| 1980's | 1990's |
|---|---|
|
I'm working on task or project X.
|
I'm working on task or project X.
|
The huge shift here was moving from an application-centric model of working to a document-centric one. It was now easy to group of all of a project's documents into a single folder or window, regardless of varying types. The applications were just afterthoughts.
In the 00's ("aughties"?), networking is everywhere; it's a pervasive part of our daily tasks. At least half of my desk job today involves two-way communication. If you pulled the network cable out of my computer, I'd barely be able to do my job: everything is about collaboration now.
I have this routine. I work on documents for a while (writing, coding, etc.), then every ten minutes I "poll" for incoming communications. I have communication applications running in the background, typically running on separate virtual desktops:
For example, right now I'm working on a programming project that involves collaboration with two other people: Brian and Peter. Much of the time they're not in the same room with me. So as I'm working I feel compelled to "poll" for their messages. Did any important emails come in from either of them? Did either of them ask for me in the multiple chat rooms I'm listening to? Did they send me any instant messages or calendar invitations or meetings? How about incoming VoIP calls? I find myself flipping between these big communication apps, looking for signs.
Similarly, I might be working, and suddenly realize I need to ask one of them a question. "Hmm, how shall I ask?" I decide on the medium, launch (or switch) correct application, and type my message.
Notice the familiar 1980's pattern here? All of my communication is still application-centric:
|
I'm working on task or project X.
|
So what's the alternative?
My idea is that it's time for the paradigm shift to catch up with the Internet. Just like the GUI folks figured out that tasks should revolve around documents (and not applications), we need to change our UIs to make communication revolve around people, not applications.
Imagine a GUI in which a person were represented by a single icon. When I open a task-specific folder, I not only see relevant documents, but relevant people as well. In my case, I'd see an icon for Brian, and and one for Peter.
The "people" icons are objects with built in communication abilities. When I right-click on a document, the contextual menu gives a choice of applications to launch; but when I right-click on the Brian object, the contextual menu gives me a list of ways to communicate with him:
The underlying system already has my communication applications running quietly in the background, perhaps invisible to me unless I ask. Just as clicking on a URL document opens the web page in my "preferred" web browser, sending a message to Brian automatically brings up my "preferred" email/IM/IRC client, already addressed and ready to go. When I finish sending the message, the communication app goes back into hiding.
These "people" objects could also have read-methods built in, not just write-methods. Assuming that the underlying system is logging everything, it should be easy for me to run quick queries on Brian: "show me all the emails he's sent me", or "show me all IM dialogues with Brian in the last two weeks".
Note that a communication object doesn't just have to be about people. It could also represent a group of people — say, all the folks working on a project. With a simple context menu click, I could send an email to the group's shared mailing list, or send a message to a shared chat room.
This is what I mean by a "person-centric" communication shift. Instead of the 1980's application-centric working style, we get something much nicer:
| 1990's | 2000's |
|---|---|
|
I'm working on task or project X.
|
I'm working on task or project X.
|
If these "person" or "group" communication icons existed as first-class objects in a GUI, the first thing I'd do is write a nice aggregator.
Imagine a two-dimensional array of these communication icons, all living in a single application window. Each icon represents either a single person or a group of people. Whenever a message comes in (through any communication medium), the appropriate icon lights up. I'd call it my "Switchboard" application. Instead of manually polling four applications every ten minutes, I'd only have to look in one place for all incoming communication. When I click on a lit-up icon, the appropriate communication app pops up to show me the message.
Of course, the Switchboard app could be used to send messages as well as receive them. And I imagine it would allow you to make yourself globally "away" or "available" to all of your communication channels too.
Boy, that would be nice.