FutureComm: An experiment in integrated messaging (part 2)
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.
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.
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.
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.
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.
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.
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.
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.
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
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.