FutureComm: An experiment in integrated messaging

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.
    
    
• 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).

E-mail

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.