FutureComm: An experiment in integrated messaging (part 2)

Jim Miller
Miramontes Computing
November, 2001

Return to Part 1...

Voice

The interface for voice services was perhaps the most explicit case of applying a single overall design across the entire system. Here, the goal was to make the handling of voice mail as close as possible to that of e-mail. The main E-mail and Voice pages use the same design, the only difference being that voice messages are described not in terms of their size, but their length. As with e-mail, messages can be filed into folders, and the messages are in most cases identified as coming from specific people rather than just phone numbers. The interface also supports multiple voice mailboxes in much the same way as the e-mail interface supported multiple e-mail accounts. The configuration panel for voice services allows the user to specify the voice mail accounts to be handled by the system, and a popup menu on the main panel provides access to the different accounts.

There are of course differences between e-mail and voice mail that must be addressed by the interface. Clicking on the subject of a message again takes the user to a window devoted to this message, two forms of which are available in the window. The audio recording can be played back through a media controller, which allows the user to start and stop the playback of the recording. A text version of the message is also provided, presumably by running the recording through a speech recognition system. This text version is also used to generate the "subject" of the message, used in the main voice mail page. Since there is no explicit notion of "subject" in a voice mail message, something else must be used. The design here simply uses the first few words of the message as the subject; other techniques for this purpose, perhaps making use of information retrieval technologies, could also be explored.

The message window also offers buttons to reply to or forward the voice message, which raises another difference between voice mail and e-mail: what does it means to send a voice mail message from a computer-based system such as FutureComm? One possibility is that the user's telephone is physically integrated into FutureComm, such that voice messages can be initiated by clicking on a telephone number on the screen, and created by speaking into the telephone. This scenario would require the user to identify the telephone to be used for this purpose, and be open to different telephones being used at different times (e.g., home vs. office). The VoiceConnect section of the main Voice page supports this need, through a popup menu that allows the user to select one of the telephone numbers specified in his configuration of FutureComm, and potentially to any number he might specify.

If this approach is not practical, FutureComm offers a text-based way to create or reply to voice messages. Here, the user can type the message into a text field, and the recipients of the message can be specified by their phone numbers or by selecting them from a reduced version of the Address Book. A speech synthesis system can then generate a sound file containing a spoken version of the message, perhaps with the user's choice of voices, and FutureComm can forward the message to the selected telephone numbers. The Forward and Reply screens are built in a comparable way, except that they include the recorded and text versions of the original message.

Instant messages

The instant message component of FutureComm was designed to support a messaging infrastructure that provides access to a number of different instant message services -- a native CommCo service as well as those offered by America Online and MSN. FutureComm further expands the notion of instant messaging by treating pagers and SMS-enabled cell phones as other types of instant messaging devices, ones that, despite their differences, should served by the same FutureComm interface as traditional instant message clients.

The instant message component of FutureComm's CommPoint is meant to cover all these ways of instantly sending a message to someone. The Address Book entry for a person can support up to four instant message accounts, one of which can be selected as the "preferred" client. These accounts are then made available to the instant messaging component of CommPoint: Clicking on a user's instant message icon in CommPoint brings up a small action window where the user can select the desired client for the recipient of the message and enter the message itself. The main Instant Messages screen in FutureComm provides an expanded view of the people in the user's CommPoint, showing their individual instant message accounts and, where possible, their logged-in status for each.

In a similar way, the Instant Message Configure screen allows the user to configure his instant message preferences for proper handling by FutureComm. Up to four instant message accounts can be specified, in addition to the CommCo account created as part of the user's registration with FutureComm. The screen enables the user to specify the screen name and password of each account, as well as such details as whether FutureComm should automatically log the user into that instant message account when he logs into FutureComm, and whether the user should be logged into that account right now, and thereby be currently visible to other instant messaging users.

Beyond this, FutureComm's design assumes that the real work of instant messaging is handled by a separate client application. The action window collects the message to be sent and forwards it to the appropriate instant messaging application that actually sends it. This is necessary because of the way that instant messaging systems receive messages for their users at arbitrary times: a browser-based system limited to HTML and JavaScript simply can't do this. It would be possible to build a Java or ActiveX applet that resides inside a FutureComm page, establishes a live connection to the instant messaging server, and handles messages as they arrive. However, the use of such applets was ruled out by the project's original design specification, and, in any case, an applet-based approach would only work as long as the page containing the applet is loaded into the browser. Once the browser moves to a different page, the applet is gone and the connection to the server is lost. Therefore, for now, relying on an external client for instant messaging support appears to be the best approach.

Address Book

The FutureComm Address Book provides the capabilities of most address books: users can create entries for people, containing home and business addresses, multiple phone numbers, e-mail addresses, instant message accounts, and the like. In FutureComm, these contacts can be created by entering the appropriate information into an empty form, or by searching for members in a FutureComm member directory. As noted in the earlier discussion of FutureComm Friends, creating a contact from a user's directory entry will generally provide access to the information in that user's public profile. However, if the user has been identified as a FutureComm Friend of the person whose entry they are adding, they will receive whatever information that person specified in his Friends profile. Regardless of how the entry was created, the user has the option of including that person in his CommPoint; this selection may be changed at any time, and his CommPoint will be appropriately updated.

The My profile section of the Address Book contains the screens where the user may create his public and Friends profiles. Creating either of these profiles is completely optional; the information in these profiles can also be changed at any time. If the user changes information in his Friends profile, his Friends are notified of those changes, so that their address books can be kept up to date. The Friends must acknowledge these changes before they are made, thereby preserving their personal control over the contents of their own Address Books.

The Friends section of the My profile area of the Address Book is where the user can specify his FutureComm Friends, by selecting the desired people from a reduced version of the Address Book. Again, a user's list of FutureComm Friends can be changed at any time. Removing someone's status as a Friend will not remove information from the ex-Friend's address book, but it will keep them from receiving future updates from that user. Finally, note that Friends are specific to the FutureComm user ID under which they are created: different members of a family sharing a FutureComm account can have separate lists of Friends. Similarly, a user who creates a work-related ID and a home-related ID can have different sets of Friends associated with those IDs.

Calendar

Like the Address Book, the Calendar offers a relatively standard set of scheduling capabilities. Events are created with a date, time, subject, and other related features. Once created, they appear in a calendar which can be configured to show either a month or day view; navigation tools allow the user to show events on different dates. Clicking on an event's subject in a calendar opens a small window showing the details of the event, and allows the user to change those details.

The calendar includes a simple groupware feature, through which a user can invite other people to an event. These people receive a notification of this invitation on their Home pages and on their Calendar pages; clicking on it opens a window that summarizes the event and allows them to accept or reject the invitation. Once accepted, the meeting is added to their calendars.

Finally, when a user creates a calendar event, he can specify that the event should be visible to his set of FutureComm Friends. If he does so, that event can be presented as part of his Friends' calendars. The display of these forwarded events is controlled by the checkbox at the top of the calendar, thereby allowing the Friends to retain control of their own calendars.

FileSpace

The FileSpace component of FutureComm provides its users with a network-based file storage and retrieval service. Files can be uploaded and downloaded to a FutureComm server through a simple set of web pages, and can be organized into folders. These folders are used to provide not only personal file storage, but also storage that is available to other FutureComm members. Folders can be created that are visible to the "public" -- any FutureComm member -- or to the restricted set of FutureComm Friends. The Members popup menu in the command bar allows users to see the files available to them in another member's FileSpace. The current demo does not address the question of protection levels for these folder sets; perhaps Friends could drop documents into a user's Friends FileSpace, while the public FileSpace could be read-only.

This design for network-based access to files does not make any commitments to the implementation strategy underneath it. Some discussions about the capabilities of future mail servers suggested that those servers could provide these kinds of services. However, FileSpace could also be built on top of a server with a standard file system and an FTP server. Resolving this is a question beyond the scope of the current work.

CommSites

Another set of discussions about integrated messaging and future directions for CommNet raised the possibility of making it significantly easier for users to create web content. Rather than requiring users to build web pages with HTML, could they "e-mail a photograph to a website", and have it automatically appear on the site? These speculations motivated the design of FutureComm's CommSites. This is the most speculative feature in the FutureComm design exercise -- it's almost a pure gedankenexperiment, but it raises a number of interesting possibilities.

The key idea behind CommSites is to take the effort that is currently required to create a content-laden website and divide it among several parties. Consider an "e-mail a photograph" site like the demo's Miller Family Photos. The end-users -- the people providing the pictures and caption -- have an easy job: they put a picture and a caption into an e-mail message or a simple web-based form, click a button, and the content shows up on the CommSite. In doing so, they're providing content that will be plugged into a template that was set up by someone else, most likely the master user of a FutureComm account. This person didn't create the template -- that would be done by some person or company with programming skills. In this scenario, the photography site template would most likely be created by a company, such as Kodak (note: Kodak's involvement here is pure speculation; they have not been contacted in any way regarding this work), that wants to encourage people to do more with photography. The template contains the basic style (or possible styles) of the page and the core functionality of posting and sharing photographs. It's up to the person setting up the CommSite -- the FutureComm member who wants his family members to be able to post family photos, and so creates Miller Family Photos -- to personalize the template for his own use.

CommSite templates might be created by different companies for different reasons. CommCo might offer a weblog template to generally spur FutureComm traffic and add value to FutureComm; music companies might build a template that would help musicians post sound clips of their bands' performances. Individuals -- people with enough programming skill to construct a template -- might also be able to build templates, but this would depend on the nature of the tools and the business models underlying CommSites. In doing so, the template creators are presumed to be building on services that FutureComm provides in support of CommSites. These services have yet to be fully defined, but they would most likely include:

  • Template completion: FutureComm could provide a simple tool to merge end-user submissions with style specifications and with existing site contents. In most cases, this should be a relatively simple matter of inserting the submitted elements into an HTML template and adding it to the other content of the CommSite, but it's a process that could easily be mechanized to assist the producers of site templates.

  • User authentication: In the scenario of the Miller Family Photos CommSite, it's assumed to be important that access to the CommSite be limited to family members, as noted by the list of "members" shown in the CommSite's palette area. FutureComm could support this by maintaining databases of user groups and sites, and authenticating users prior to their entry to the CommSite. People who are FutureComm members could be authenticated when they log into FutureComm. People who are not FutureComm members might still be able to access the CommSite through a standard web browser, given the URL of the CommSite and a unique ID and password, assigned by some FutureComm-based registration process. Of course, CommSites could also be designated as public sites, accessible to anyone.

  • Distribution and advertising; integration with FutureComm: FutureComm could provide a directory of publicly accessible CommSites, enabling users to find CommSites of interest to them. A simple "bookmark" system, built into FutureComm and shown in the screen above, could allow users to "subscribe" to certain sites, and FutureComm could notify them when their sites have new content.

At this point in the CommSites gedankenexperiment, several questions need to be answered to evaluate the utility of the idea. To consider three of them here:

  • Is the space of problems that can be solved by this approach -- the aggregation of end-user content by a customized template and the distribution of this content to either the public or a restricted set of people -- large enough to be worth doing? Several rounds of brainstorming possible CommSites would be a good way to start estimating the market opportunity for this feature.

  • Do the services provided by FutureComm as part of the CommSites package offer enough value to motivate service providers (e.g., Kodak) to take part in the program as opposed to simply building proprietary websites offering comparable services? There is no shortage of websites offering the construction of simple home pages, weblogs, and the like; FutureComm and CommSites need to offer special value to draw template developers to this platform.

  • Is the process of turning a generic template into a specific CommSite simple enough that a reasonably large collection of people -- the "master users" referred to earlier -- will not only choose to do so, but in fact be able to do so? Part of the bet behind CommSites is that the division of labor it proposes is both economically viable and a good match to the skill sets of the targeted groups. There is an opportunity here, but moving ahead with the idea would require careful thought and study.

Search

The search component in FutureComm takes advantage of a future integrated messaging architecture by allowing search over all content types that, one way or another, can take on a textual form. A search engine underlying FutureComm should certainly include e-mail, address book and calendar entries, and files stored in FileShare, both personal and shared. In addition, since voice mail messages are already being transcribed by speech recognition software for presentation in the Voice module, they can also be included in the search. It's further plausible to assume that the search process could be further extended to include a full web search, as well as a search of intranets for corporate installations. The result is an exceptionally broad-based search capability, one where users no longer have to remember whether the document they were looking for was in their e-mail, somewhere on the web, or in a document on their computer.

The search form itself is relatively standard, with the addition of controls to allow the user to choose which information stores should be searched -- e-mail, voice mail, etc. On the assumption that the search engine underlying this interface permits date-based search, fields for specifying those parameters are present as well. Finally, the user may request that the search results be ordered by content type, date, or search relevance.

Executing the search returns a page of search results whose design is consistent with that of other parts of FutureComm, with the addition of a relevancy indicator. The results can also be re-ordered through the popup menu at the top of the search form.

The search results page makes use of the palette area in two ways. First, the parameters of the most recently-executed page are preserved and presented in a small form, so that incremental changes to a search request can be made easily. Second, search results are saved for re-execution at a later time. These searches appear in the SearchPoint, a palette somewhat similar to the CommPoint. Past searches can appear in the SearchPoint in two ways. Users can give a name to a search request and save it permanently; this is meant to be used for those cases where the search is likely to be needed for re-execution over a period of days, weeks, or longer. These are the items at the top of the SearchPoint -- Look for firewall hardware et al. If a search request is not given a name and saved, a representation of the search -- the first few keywords in the search -- are added to the lower section of the SearchPoint. This part of the SearchPoint is meant to support the need to re-execute a search that was requested recently, but that was not deemed important enough to warrant being saved permanently, or whose value only becomes apparent later. There are a limited number of slots for these unnamed search requests, and incoming requests move through these slots in a first-in-first-out manner.

In closing: Open questions and next steps

FutureComm was a very quick design experiment -- the vast majority of the work was done in less than a month, with a couple of additional weeks allocated to discussion with CommCo staff, evaluation, and revision. It goes without saying that there are a number of open issues surrounding FutureComm and how it deals with Internet-based communication. Some of these have been discussed already; a few other, more generic issues are considered here.

  • Alternative interface designs. Overall, the attempt to apply a single interface style to all the components of FutureComm worked reasonably well. This, of course, does not mean that alternate approaches to FutureComm's graphic design might not be appropriate, or even better. The basic concepts underlying FutureComm are general enough that they should adapt well to alternative designs driven by the needs of brandings by different customers. Some very simple experiments in this regard can be seen by going to the Home page and clicking on the word "Home" at the top of the work area -- this will cycle through a few quick designs meant to address how ISPs or corporate customers could make use of FutureComm's features in different ways. No attempt was made to address end-user customization of the exact modules included on various pages, such as that offered by My Yahoo and other similar portal sites. This would surely be possible, and may be of special value as part of design experiments for ISP or corporate versions of FutureComm.

  • Finally, it would be worth considering the entire design premise considered above -- whether slavishly carrying the same design across all FutureComm modules is the right thing. The appropriateness of this design strategy might differ across markets: it could make sense in corporate environments, but not in consumer services. While it would be wrong to say that America Online, for instance, doesn't have a consistent design language throughout its service, its pages surely show a broader range of visual design than does FutureComm.

  • Universal compose and reply? Currently, FutureComm restricts messages to a single content type, and restricts replies to messages to remain in the same content type as the original. That is, users must initially choose which content type they want to use for a message -- e-mail, voice mail, etc. -- and an e-mail message can only be replied to with an e-mail message. It's interesting to think about a more general system, in which FutureComm's messaging components can be used together: A message might be sent to one person through e-mail, to a second through voice mail, and to a third through an instant message. Several of the aspects of FutureComm's design would have to be rethought to support this, but it's an intriguing possibility.

  • Single or multiple folder sets? The desire to integrate the different communication and information types addressed by FutureComm raises the question of whether the folders used for filing messages and other content should be the same across the different content types. This question strikes at a difficult question about the kinds of tasks that FutureComm is meant to address. It's easy to imagine high-level tasks that span communication types, and the desire to have a folder representing such tasks is clear: I want all of my FutureComm stuff to be in the same folder; in fact, I want to be able, in some way, to open that folder and see all of it, in a single view. However, other aspects of the folder and filing system are less generic, and fit this general model less successfully. It's easy to imagine a "Project meetings" folder in the Calendar tool and a "Sales leads" folder in the Address Book, but it's less clear how useful those folders would be in FutureComm components other than the ones just mentioned. In the near term, there's no reason that a user can't give folders in the different components the same name when it's appropriate; in the long term, this question, and the functionality implied by sharing folders across components, deserves further study.

There are obvious directions for continued work on FutureComm, should it be appropriate. While user issues have always been the primary drivers of FutureComm's design, the time is surely ripe for user testing and subsequent revision of the design. It would also be useful to consider backend implementation strategies for FutureComm's services, with a special eye towards scalability. CommSites deserve special attention here, since its model of collaborating services is the most speculative of any part of the prototype. Finally, it is time to take the work seriously as a business concept, and begin a careful marketing evaluation of FutureComm. There are a lot of ideas in FutureComm, and it would be important to develop a good understanding of the relative value of them, and, if deemed valuable, how the different features of FutureComm could best be rolled out over several staged product releases. But, overall, FutureComm is an intriguing sketch of integrated messaging, and raises a number of questions that would be well worth answering.