FutureComm: An experiment in integrated messaging
In retrospect...
The goal of this project was to look beyond the client's then-current consumer Internet service and explore ways in which its full range of services -- Internet, telecomm, and beyond -- could be merged into a single, integrated package. I really liked the result, as did the client, but, just as we finished this initial phase of the work, the company made a C-level decision to move away from consumer communications in favor of corporate datacomm. Such is life. But time passes and technology (especially VoIP) advances, and now these kinds of systems are beginning to appear (for instance, here), offering many -- but still not all -- of the ideas presented here. It's about time.
Given the communication and collaboration aspects of this project, I couldn't help but slip in a bit of my earlier AppleFamily work here, under the guise of CommSites. Here, I started with the AppleFamily notion of information and media sharing among family members or other groups and added the ability of companies to provide collaboration templates through which the members of the CommSite to share and even extend their own content as well as company-provided content. I think it's a nice extension of the present-day interest in collaboration driven by user-generated content.
Preface: I've received permission from the client who sponsored the FutureComm project to make this report publicly available. However, for privacy reasons, I've replaced any references to the sponsoring company and existing products with the anonymous (and fictitious) "CommCo" and "CommNet", and identifying marks have been removed from images.
Executive summary
FutureComm is a user interface design prototype of a future Internet and telephony communication suite. It takes CommCo's CommNet as its starting point and presents a design of an enhanced future version of CommNet, one that might appear 18 to 36 months after the initial product release. The focus of the prototype is on the design of the user interface rather than the invention of new communication technology: the design is intentionally limited to the technology available in CommNet and other capabilities available within CommCo.
To this end, FutureComm provides an integrated, web-based interface to e-mail, voice mail, instant messaging, calendar and address book tools, remote file access, search, and customer registration. A single design language is used throughout FutureComm, as a means of emphasizing the integrated nature of the communication tools it supports. In the process of designing FutureComm, several key ideas emerged and played central roles in the design, including:
- Using representations of people and messages as interfaces
for creating and viewing messages.
- Exploiting the 80/20 rule: Simplifying communication
with those people that are most likely to be the target
of communications.
- Merging presence indicators and action techniques.
- Simplifying secure information sharing among friends and colleagues.
Ultimately, the FutureComm experiment supports the notion that a uniform, integrated approach to messaging can be practical and effective. Appropriate next steps for the work include prototyping backend support for FutureComm, user testing and refinement of FutureComm's interaction concepts, marketing evaluations, and analysis of how the many features found in FutureComm could best be staged into a product release plan.
FutureComm: Beginnings of the project
The FutureComm project began with a plan by CommCo staff to consider the user interface design of future versions of CommNet -- an integrated suite of Internet and telephony communication tools under development by CommCo. When the project began (July 2001), the first release of CommNet was about to ship, and CommCo staff were interested in how future versions of CommNet could evolve to take on more of the technical and marketing vision of an integrated messaging architecture. The technologies that made up that architecture -- unified access to different instances of different messaging system -- were well understood; what was less clear was how those technologies could be effectively tied together into a clear, easy-to-use user interface. Thus, this project was started, with the charter of prototyping a user interface for a more advanced version of CommNet, one that might appear 18 to 36 months after its original release. The intent of the project was to be innovative, but to remain within the general set of technologies already present in CommNet, or that could easily be obtained from elsewhere in CommCo.
This prototype of a possible future for CommNet, described here, will be referred to as FutureComm, to avoid confusion with the currently-shipping CommNet. FutureComm's design supports the communication capabilities offered by CommNet -- e-mail, instant messaging, and a network-based address book and calendar -- as well as voice mail. Where possible, it is also meant to address other messaging issues, such as:
- Uniform treatment of all communication modalities:
The interface should offer a consistent appearance and
style of interaction for all communication types. The
act of sending a message should be consistent throughout
the system, regardless of the kind of message being sent.
- Major communication acts are a click away: The
design center of the system is sending and receiving
messages. It should be possible to carry out these actions
without forcing the user to navigate through multiple
levels of menus, windows, or dialogue boxes.
- Presence and action: Most people have a relatively
small set of other people that they most frequently communicate
with. The system should make it especially easy to contact
those people, and should provide some assistance in discovering
which of these people is within reach of the system,
and how the user might best use the system to contact
them.
- Identity: People often need, or at least want,
to be able to log into an Internet service with different
identities. This is not necessarily the result of a desire
to conceal themselves, but can rather be a recognition
of the fact that people have different communication
needs in different settings -- at home vs. at work, for
instance. The value of these alternative identities increases
as more capabilities are associated with the service:
When at home, a user may not want to be notified of work
voice mail, may not be able to check e-mail on servers
behind firewalls at work, and may want to announce his
presence to different people through instant messaging
systems.
- Information sharing and privacy: The Internet
can make it very easy for people to share information
about themselves with their friends -- personal contact
information, documents, calendar events, and so on. However,
this sharing must be done in such a way that the users
maintain control over it -- in particular, the shared
information must be available only to those people that
the user wants to have it.
- Easy access to server-based technologies: Many
Internet technologies have not been widely adopted because
they require more interest in, skill with, or access
to computer technologies than most people have. As a
result, people live with limitations that could be solved
through these technologies, while other problems are
addressed in clumsy ways. For instance, having a set
of files that can be accessed from anywhere in the world
can be quite valuable to the business traveler, but this
requires having access to an appropriately configured
server (one that lets the traveler in but keeps everyone
else out), appropriate client-side software to retrieve
the files (which needs to be available wherever the traveler
might happen to be), and the expertise to get the files
to and from the server. Faced with these barriers, many
people give up on finding an elegant solution, and resort
to such tricks as e-mailing a document to a web-based
e-mail address before a trip, so that it can be downloaded
on arrival. This approach is both ingenious and functional,
but it is also clumsy and potentially damaging to corporate
security. Similarly, many people lack the skills and
server access needed to create a simple web page, and
thus miss out on the ability to distribute information
on the web. Finding good solutions to these problems
could significantly increase the value of future versions
of CommNet.
- Tying it all together: Point solutions exist for most of the problems noted above -- web-based e-mail systems make it easy to create multiple e-mail addresses, most instant messaging systems support multiple screen names, and there are plenty of free or inexpensive web-based services that offer remote file storage and simple web site development. Part of the assumption behind CommNet and its potential successors is that there is value, and a significant opportunity, in tying these point solutions together into a single system that, through its integration, is significantly more powerful and easier to use.
FutureComm: State of the demo. FutureComm is purely a design exercise: it exists as a set of web pages, built with HTML and JavaScript. The pages are linked together to simulate how a completely implemented version of FutureComm would behave, but this is ultimately only a simulation. This document will often use phrasing like "FutureComm addresses this need by doing the following ", implying that there is backend code able to carry out the process. However, this is purely a rhetorical convenience: at this time, no backend support has been implemented for any of the actions shown here.
Part of the vision behind CommNet is that messaging is an activity that should be supported by many different kinds of devices -- the desktop to be sure, but also wireless handheld devices, with either small, pen-oriented displays or speech interfaces. Prototyping all these aspects of the messaging domain was beyond the scope of this project; for time and resource reasons, this study of FutureComm was focused on the development of a web-based client to an integrated messaging system. How FutureComm could provide a consistent messaging experience across different devices and interaction styles is a quite valid question, but its answer will have to wait for another study.
FutureCom's basic screen design
One of the design principles underlying FutureComm was the use of a single general screen design throughout the entire system. This supported the intent of presenting a unified approach to the various messaging technologies, and was also an exercise to see how well a single design could satisfy all the needs of those technologies.
The typical FutureComm screen (Figure 1) can be broken down into three major components:
- Header: The top of the screen contains three
horizontal bars that allow the user to navigate his way
through the various parts of FutureComm. These are:
- Banner: The uppermost part of the screen
is a banner containing branding information, the
user name (once logged in), and six buttons that
provide universal access to widely-useful functions. Back and Forward buttons
support movement through the pages shown in the
browser; they're needed since FutureComm is presented
in a browser window without the standard back and forward controls,
and it sometimes needs to control exactly how a back request
should be handled. Update refreshes the
current contents of the window with new content
from the server, such as newly-arrived e-mail messages. New
e-mail provides a quick link to creating an
e-mail message, available anywhere in FutureComm. Help launches
a help system; the specification of this system
was beyond the scope of the current work. Logout logs
the user out of the system.
- Navigation Bar: These buttons allow the
user to move between the major components of FutureComm: E-mail, Voice,
etc.
- Command Bar: This bar contains commands
that support the specific task being carried out
by the user; its contents frequently change as
the user moves from screen to screen.
- Banner: The uppermost part of the screen
is a banner containing branding information, the
user name (once logged in), and six buttons that
provide universal access to widely-useful functions. Back and Forward buttons
support movement through the pages shown in the
browser; they're needed since FutureComm is presented
in a browser window without the standard back and forward controls,
and it sometimes needs to control exactly how a back request
should be handled. Update refreshes the
current contents of the window with new content
from the server, such as newly-arrived e-mail messages. New
e-mail provides a quick link to creating an
e-mail message, available anywhere in FutureComm. Help launches
a help system; the specification of this system
was beyond the scope of the current work. Logout logs
the user out of the system.
- Work area: The large area on the left side of
the screen, which contains whatever elements are needed
to support the selected task.
- Palettes: A column of small elements on the right side of the screen, which contain various tools that support the task in the work area and the overall tasks of FutureComm.

The visual elements of FutureComm's design were borrowed from those of the initial CommNet release. These were used simply because they were convenient; there is little about FutureComm's design that requires these specific elements.
Key ideas in FutureComm
As the design of FutureComm evolved, some "big ideas" began to appear. These are ultimately responses to the initial questions and concerns that motivated the project; since their functionality has implications throughout FutureComm, it's appropriate to discuss them here, before moving into the system's specific capabilities.
Live
representations of people and information. Wherever
possible, FutureComm represents the people involved in
a message with their "real" names, rather than
with e-mail addresses, phone numbers, or other messaging-dependent
strings. This is presumably done by searching for the
string in the user's address book, and substituting the
name of the corresponding person for that string. In
addition, FutureComm makes those names "live",
so that clicking on them produces an action window containing
a display of what FutureComm knows about that person,
and opportunities to communicate with that person. The
contents of this window can easily be found by reference
to the Address Book, through the same search process
that yielded the person's name. From this window, clicking
on one of the content types -- phone, e-mail, etc. --
will take the user to the appropriate part of FutureComm,
set up to, for instance, send an e-mail to that person.
Since, as will be noted later, FutureComm supports multiple
addresses for the various messaging types, pop-up menus
allow the user to selected the desired address before
invoking the action. When multiple addresses exist for
a contact type, the primary contact address, as specified
in the user's address book, is shown as the default address.
In
a similar way, clicking on an e-mail address, telephone
number, or instant message screen name in a FutureComm
window brings up an action window.
This window corresponds
to the type of information selected: clicking on an e-mail
address offers the user the ability to send an e-mail message
to that person. Alternate e-mail addresses, if any, are
available through the popup menu in the form.
CommPoint: A tool for presence and action. The CommPoint feature of FutureComm addresses two aspects of communication, Internet-based and otherwise. First, most people have collections of people that they contact frequently, and FutureComm should make it especially easy to contact them. Second, there is value in knowing which of those people are currently within reach of FutureComm, as the "buddy lists" common to instant messaging applications have demonstrated. Of course, FutureComm's needs are somewhat different, due to its broader coverage of communication media.
CommPoint
provides a way to address those concerns. It presents a
user-created list of contacts -- groups as well as individuals
-- and provides both presence information about those people
and efficient ways of contacting them. Clicking on the
name of a person in CommPoint produces a person-oriented
action window like that shown earlier. The CommPoint icons
to the right of the name offer quick ways of contacting
the person by telephone, e-mail, and instant messaging,
through an action window focused on that communications
type. Where possible, the icons also report whether the
person is known to be reachable by the messaging tool in
question. A "happy face" instant message icon
indicates that the person can be reached through an instant
messaging system, while a crossed-out "sad face" icon
indicates that they cannot currently be reached in this
way.
People can be included in a user's CommPoint in two ways. First, users can specify in their Address Book that a certain person should always be included -- these people appear at the top of the CommPoint list. CommPoint also includes a few slots for people who have not explicitly been included in CommPoint, but who have recently been contacted by the user. The algorithm for choosing these people has not been specified here. The simplest technique would be a "first-in, first-out" stack, so that new people replace old people as messages are sent. The exact number of entries allowed in CommPoint is also unspecified, but is presumably a system parameter that starts with a reasonable, but changeable default value.
Another unanswered question about CommPoint is the extent to which it can provide presence information other than a user's availability through instant messaging. This depends on the backend capabilities of FutureComm. FutureComm should be able to tell which of the people in CommPoint are logged into FutureComm, and so should be able to provide presence information about their accessibility through e-mail and telephone. In a similar way, FutureComm may be able to tell whether a person's cell phone is turned on, and so reachable by either telephone or SMS messages. These issues raise the question of whether the people who appear in CommPoint must be FutureComm subscribers, either for marketing reasons or because, as a practical matter, FutureComm might only have access to presence information for FutureComm members.
Ultimately, the value of CommPoint is that it offers a great deal of valuable functionality in a very small amount of space. Consequently, it can be included in the palette section of most FutureComm screens, and can effectively support users' communications needs throughout FutureComm.
FutureComm Friends: Information sharing between members. Assume for the moment that FutureComm offers some sort of member directory, similar to that on America Online. This directory would contain listings that users create for themselves, to be made available to other members through some sort of directory or search function. The obvious problem with such a directory is that the information available in it is available to all the members of the service. People are by now either sufficiently knowledgeable or paranoid about the Internet to not want to distribute highly personal information about themselves in this way. As a result, these profiles are frequently underused, and the opportunity of being able to use the Internet to securely distribute personal information to a chosen set of friends is lost.
FutureComm addresses this issue through FutureComm Friends. This is a list of other FutureComm members, specified by a user in his Address Book, with whom the user wants to be able to share information. The most direct use of FutureComm Friends is in the member profile: Users are able to create two distinct profiles: one that is visible to any FutureComm member, and another, presumably more informative one, that is visible only to that user's FutureComm Friends. Thus, a user could disclose his home address and phone number to his Friends, but not to the general public. FutureComm Friends affect other parts of FutureComm as well: users can make certain items on their calendars available to their friends (e.g., "Out of town this week"), and they can make documents available to their friends through the FileShare section of FutureComm. For now, the thing to note is the ability of FutureComm to facilitate the creation of communities within its subscriber base, and to draw users to the service by the offering of these unique capabilities.
The modules of FutureComm
FutureComm is built from one large browser window; push buttons in the navigation bar allow users to switch the window's focus from one task to another. There is not a general concept of having two FutureComm windows open at the same time, although users can always force a second window to be open via the "Open link in new window" browser operation. Note that that this ability, which can't be ruled out, could have implications for the design of FutureComm's backend.
FutureComm supports ten specific tasks; they are:
- Registration: Sign up as a user and create the
user IDs to be used in the service.
- Home: The home page for FutureComm, with notifications
of new messages and other system actions relevant to
the user.
- E-mail: Send and receive e-mail.
- Voice: Send and receive voice mail, and specify
the connections between the user's telephone service
and FutureComm.
- Instant message: Send and receive instant messages.
- Addresses: Create address book entries for contacts,
and maintain personal profiles for the service.
- Calendar: Create events on a web-based calendar.
- FileSpace: Store files in a central, web-accessible
server for later download, and share files with other
members.
- CommSites: Easy creation of web content.
- Search: Search all the information stores of FutureComm.
Registration
When the FutureComm demo is launched, the user is shown a page that handles the registration process for a new FutureComm member. An initial screen collects the member's name and address, other contact information, and credit card / billing information. At this point, the screen's header offers only a "help" button, and there is neither a navigation bar nor a command bar. These features will not appear until the user has successfully registered and is fully logged into FutureComm.
Once
this information has been collected and verified, the
user is asked to create a master ID. Every FutureComm
account has exactly one master ID, corresponding to the
person responsible for the FutureComm account and for
all billing issues. This ID must be unique in a namespace
associated with FutureComm, since it will become the
user's e-mail address and instant messaging screen name.
Once a valid ID has been created, the user specifies
which of FutureComm's services should be included in
the FutureComm navigation bar. This is in keeping with
a request to make FutureComm simple -- new users might
start with only e-mail and instant messaging, and gradually
add other services as they gain experience with FutureComm.
The master user may now create some number of additional user IDs for other family members or other purposes (e.g., "Jim at work" and "Jim at home"). The master user is the only user permitted to create these additional IDs for the account. As before, proposed IDs must be tested for uniqueness in the FutureComm namespace. The master user can also select the services to be available to this user -- a parent might allow all family members to have e-mail, but younger children might not have access to file sharing. Once all user IDs have been constructed, a screen summarizing all the IDs created for this account is presented, and the user is taken to FutureComm's home page.
Once this information has been collected and verified, the user is asked to create a master ID. Every FutureComm account has exactly one master ID, corresponding to the person responsible for the FutureComm account and for all billing issues. This ID must be unique in a namespace associated with FutureComm, since it will become the user's e-mail address and instant messaging screen name. Once a valid ID has been created, the user specifies which of FutureComm's services should be included in the FutureComm navigation bar. This is in keeping with a the intent of keeping FutureComm simple -- new users might start with only e-mail and instant messaging, and gradually add other services as they gain experience with FutureComm.
The master user may now create some number of additional user IDs for other family members or other purposes (e.g., "Jim at work" and "Jim at home"). The master user is the only user permitted to create these additional IDs for the account. As before, proposed IDs must be tested for uniqueness in the FutureComm namespace. The master user can also select the services to be available to this user -- a parent might allow all family members to have e-mail, but younger children might not have access to file sharing. Once all user IDs have been constructed, a screen summarizing all the IDs created for this account is presented, and the user is taken to FutureComm's home page.
Home
The
FutureComm home page should be thought of as something
of a home base: it's a place to go to get a summary of
all the new communications events that, for instance, might
have occurred since the previous day or a long meeting.
It displays and provides access to unread e-mail and unheard
voice mail, new updates to the calendar or address book,
and, presumably, new content in the FileSpace or friends'
CommSites, as discussed below. Clicking on these components
produces obvious actions: an e-mail message is displayed,
a voice mail message is played, and so on. As noted earlier,
clicking on a "live" user name activates an action
window from which different kinds of messages, targeted
to that person, can be created.
The home page also contains a small version of the user's calendar; it begins by showing the events for today, but can be changed to show other dates. A CommPoint is also present; the presence of both of these features can (presumably) be customized by the user. The Customize button in the command bar provides access to pages where the user can change his password, select FutureComm services (non-master users might only be able to de-select services), and create and delete user IDs (this option should only be available to the master ID user).
The
e-mail component of FutureComm is meant to offer the features
common to present-day web-based e-mail systems. The main
page shows the messages contained in the user's inbox or
a selected folder of messages; the contents of a folder
are displayed by clicking on the desired folder in the Folders palette.
Each message is shown with its priority indicator, date,
sender, subject, and size; an unread message is highlighted
with color and boldfaced text. The list of messages in
this page can be sorted by these attributes, by clicking
on the desired label in the message list's header. The
checkbox in front of each message is used to select a message
for the deletion and filing actions available in the command
bar.
The
feature that distinguishes FutureComm's e-mail support
from other web-based e-mail systems is its support for
multiple e-mail accounts. The user may configure the mail
client to manage multiple e-mail systems, taking advantage
of the integrated messaging underpinnings of FutureComm.
The popup menu at the top of the e-mail work area allows
the user to choose which account's messages should be displayed; All
accounts is also available as an option.
The procedures for reading and creating messages are relatively standard. A message is read by clicking on the message's subject in the index page. This brings up a page that shows the content of the message, allows access to any enclosures in the message, and allows the user to reply to or forward the message. The user can also save the address of the recipient in his address book, or, for spam-control purposes, block future messages from this person.
A new message can be created through the Compose button in the command bar, or the New E-mail button in the window's header. This, as with the forward and reply options in the received message display, brings up a page with a text field for the message's entry and buttons for selecting attachments. Addresses for all the fields of the message can be typed into the appropriate fields, or they can be selected from a reduced version of the address book. The message can be sent from any of the user's accounts, as selected in the popup account menu at the top of the mail form.