This is a new browser window. When finished viewing, just close this window.

User Interface Design Specification:
Jupiter Messaging

Release 1.0

Prepared for SageBrush Corporation by UI Wizards, Inc.
Author: Jeff Johnson,
UI Wizards, Inc.
Creation Date: 21 September 1998
Last Updated: 3 December 1998

This document shows a typical user-interface specification. The yellow boxes are annotations (not included in actual UI specs) that explain the document's various sections. For your convenience, listed below are the annotated sections of this document.

Annotated Sections of this Report:

Version History:

Since user-interface specifications tend to be living documents, it is a good idea to include a version history at living documents, it is a good idea to include a version history at the beginning of the document, so readers can see how it has changed. [Back to Top]




21 September 1998

Jeff Johnson

Preliminary draft

4 November 1998

Jeff Johnson

First complete draft

17 November 1998

Jeff Johnson

Incorporated feedback from dev. team

24 November 1998

Jeff Johnson

Revised based on resolution of open issues

3 December

Jeff Johnson

Revised based on more feedback from dev. team


Here, we describe the purpose of this document: to specify the UI for a Web-based Messaging application. [Back to Top]

This document specifies a user interface design for Jupiter Messaging, based on the previously prepared Jupiter Messaging Conceptual Model document and on design meetings with members of the Messaging development team. This design is also based, to the extent possible, on the SageBrush application reference design for web-based applications described in the draft user-interface specification for SageBrush Web Requisitions (draft 1.0; October 2, 1998).

This document specifies designs for the major functional facilities of Jupiter Messaging: Folder View, Folder Picker, Folder Properties, Message Compose, Message View, Address Book, Directory Lookup, Message Templates, Mail-Handling Rules, Message Search, Message Preferences, and the Messaging sub-components of MyPage.

The document begins with an overview of Messaging's major functional facilities and the expected flow between them. It next describes design concepts that pervade the entire the design. It then describes the proposed user interface for each facility, listing open design issues for each. It ends with envisioned use-scenarios that have guided the design, and an Appendix that describes ideas for inclusion in future versions of Messaging.

Jupiter Messaging Major Components

The purpose of this section is to provide an overview of the functional components that comprise the application:. [Back to Top]

Jupiter Message consists of the following user-visible components:

Figure 1 shows how the components are related in the sense that users will need direct access from one to another.

Jupiter Messaging major functional facilities and flow.

Figure 1: Jupiter Messaging major functional facilities and flow. (Grey components are parts of Jupiter, but not parts of Messaging.)

General Design Concepts

This section describes over-arching conceptual design decisions embodied in the proposed design. At the end of this section, we list unresolved issues pertaining to the general design. [Back to Top]

Overall Appearance and Layout (aka "Look")

Jupiter Messaging, like the rest of Jupiter, is a web-application that runs in a web-browser. This Messaging user-interfaces design assumes that the browser used to run Messaging is -- or has capabilities equivalent to -- one of the two most popular web-browsers: Netscape Communicator and Microsoft Internet Explorer versions 4.0 and above.

For web-based applications that run in a browser, one design choice is whether the application displays all information in a succession of windows in a single browser window or displays separate windows in addition to the browser window. One complication is that, technically speaking, three different ways to display 'separate windows' are available:

  1. JavaScript layers on the main browser window. These are not really separate windows, although they may appear so to users. In window-manager terminology, they are child windows of whatever browser frame they appear over, and so are contained entirely within it and are clipped by it. They are lightweight from an implementation standpoint. An example of such a layer is the Date Picker that is already in use in Jupiter Calendar (and will be also used in Messaging). Because of known bugs in both Netscape Communicator and Microsoft Internet Explorer, when layers appear over certain application controls (e.g., text fields, radiobuttons), the controls show 'through' the layer instead of being obscured by them. Thus, until these bugs are fixed, layers should be positioned over the offending types of controls.
  2. JavaScript dialog boxes. These are pre-defined components provided by the JavaScript toolkit for use in applications. They are classified into several types, e.g., alert, confirmation, etc. The content is restricted to a text string (e.g., an error message). The buttons are pre-defined for each dialog box type: e.g., 'OK' for alert dialog boxes, 'OK' and 'Cancel' for confirmation dialog boxes. These dialog boxes are actually separate from the browser window. They can be either application modal or not, as desired. They cannot be system modal, i.e., a dialog box cannot block users from interacting with other applications while it is awaiting the user's response. These dialog boxes are middle-weight from an implementation standpoint.
  3. Separate browser windows. Web-based applications may invoke separate browser windows to display auxiliary information or controls. Such windows can be displayed with or without the normal browser controls, as desired. They may contain any desired content. Both Netscape Communicator and Microsoft Internet Explorer allow users to enable and disable web-applications' ability to invoke separate browser windows, so Jupiter must not assume that it will always be possible to open a separate browser window. Also, separate windows cannot be modal unless the application has the proper permissions (called 'certificates'), which is uncommon. Separate browser windows are heavy-weight from an implementation standpoint.

Jupiter in general -- Jupiter Messaging in particular -- will, in the first release, use the first and perhaps the second type of extra window. Because of the problems associated with separater browser windows, Jupiter will not use separate browser windows in the first release.

The overall appearance and layout of the Messaging design will differ from that used for the current internal release of Jupiter Calendar, because it has been decided that, to the extent possible, all of Jupiter (including Calendar) should be similar to the SageBrush reference design described in the draft user-interface specification for SageBrush Web Requisitions (draft 1.0, 10/2/98). However, certain differences from that reference design will be necessary. For example, that design encompasses a single application, whereas Jupiter Messaging is one of an integrated suite of applications (including Calendar, MyPage, and Document Management). Also, Jupiter will not use the web-browsers'; kiosk mode; it will run in a normal browser that is displaying all of the browsers' controls.

Jupiter Generic Application Frame

Figure 2: Jupiter Generic Application Frame (which fills the web-browser's content area)

The general design framework for Jupiter (including Messaging) is illustrated in Figure 2. Everything that Jupiter displays (except for dialog boxes) is contained in a web-browser's content area. For brevity, the browser's content area is referred to in this document as 'the screen'.

At the top left of the screen is a toolbar to hold functions that are available throughout Jupiter, e.g., navigating between Jupiter's applications and setting Jupiter options. Although determination of general Jupiter features is outside the scope of this specification, likely candidates for this toolbar are (iconic buttons for): Logout, MyPage, Messaging, Calendar, Address Book, Search (or Directory), Preferences, and Help. Although buttons on this toolbar are labeled graphically, rollover ToopTip text giving the associated command name is provided for each.

The top middle of the screen will display a means of creating new email messages, new calendar appointments, new address book entries, etc. Ideally, this would be a drop-down menu. However, a drop-down menu won't work in this location, because the entire top global control area will most likely be a separate HTML frame, and a Create menu would have to be longer than the height of the frame and so would be clipped at the lower edge of the frame. The best alternative (and the current plan) is to use a snap-right toolbar that, when clicked, extends out to the right to show several functions (temporarily overlapping the Jupiter logo), then snaps back into its 'box' when a function is chosen or the user explicitly closes it by clicking on either a 'close' symbol on the extended bar or on the 'base' of the control. Items on this toolbar will be labeled graphically, augmented by textual tooltips. The graphical icons to represent each Jupiter application are yet to be finalized, are the graphic artist's decision, and are outside the scope of this specification.

On the top right of the display is the SageBrush Jupiter logo. Displayed in a small font just under the logo is the ID of the currently-logged-on user and the current date.

Below the top toolbar is the title of the current Jupiter application, e.g., 'Messaging'. The currently-active function of the current application follows the application name, separated by a colon (':'), e.g., 'Messaging: Compose Mail'.

Below the title is a toolbar containing application-specific functions. The application-specific toolbar for Messaging has items clustered on the extreme left and right.

The larger leftmost group contains buttons that allow for navigation between the Messaging mail folders. Most of these buttons provide direct access to a specific mail folder: Inbox, Drafts, Wastebasket, Sent Messages, My (private) folders, Public folders, and My (private) Templates, and Public Templates. An additional button invokes the Go To function, which displays a Folder Picker popup (see below), allowing users to specify a mail-folder to which the Folder View is to switch (or cancel the Go To operation).

The smaller rightmost group contains functions that are available throughout Messaging (or even Jupiter): Search Messages, Print Page.

The graphic icons that will represent each of the folders and functions on the application-specific toolbar are for the graphic artist to decide and are yet to be finalized. Tentatively, they are:

Below the application toolbar, filling most of the browser window, is the application-function content area. Jupiter applications (and specific functions thereof) can put pretty much whatever they want in this area. Command buttons and other controls that apply to specific content-elements (e.g., add an item to a scrolling list of items) are placed near the item they affect.

At the bottom of the screen is a bar containing buttons for functions that are specific to whatever particular function-window is currently displayed in the content area. The functions in this toolbar apply to the entire content area (e.g., Send, Print, Save), not to specific elements in the content area. The buttons in this toolbar are labeled textually rather than graphically.

Overall Organization and Flow

Some Messaging functionality is available from Jupiter MyPage, i.e., without explicitly executing the Messaging application. MyPage provides a view of the user's Inbox: it allows users to see what messages are there, which ones have been read, etc. It may be possible to see some of the content of messages (e.g., via popup windows) while in MyPage. To display the full content of a message, users will have to invoke the Messaging application, either by explicitly choosing it from the Jupiter Navigation toolbar, or by opening a message displayed on MyPage.

By default, the "home page" for Messaging is the user's Inbox folder. Users can change this in the Messaging Preferences.

Newly arrived email is automatically retrieved (to the Inbox) whenever the user returns to the Inbox. This includes the view of Inbox that is on MyPage (if present). Thus, no other context requires an explicit "Retrieve New Mail" function; users in other contexts retrieve mail simply by switching to the Inbox (which because the Inbox is the "home page" of Messaging, they can do simply by switching to the Messaging application) or to MyPage. However, when users are already viewing the Inbox or MyPage, they may want to force Jupiter to retrieve new messages. Thus, Inbox and MyPage provide an explicit "Retrieve New Mail" function.

Wherever a user is in the application structure and task flow, if s/he needs information that another component of Messaging provides, it should be directly accessible from the user's current context, rather than requiring the user to exit the current context, invoke the component or function that has the desired information, get the information, and re-invoke the previous context. Thus, for example, if a user is composing an email message and needs to look up an address, an address-chooser that accesses the users directory should be available in the Message Compose window. This contrasts with a design that requires the user to cancel the message composition, invoke the directory, look up the address, and then re-invoke the compose email function.

Jupiter Messaging will use separate dialog boxes in browsers that support them. Dialog boxes will be used when executing a function requires gathering additional arguments or data from the user. Dialog boxes make it easier for users to keep track of their current context as they execute functions, in contrast with a design that constantly replaces the user's task-context with temporary displays, forms, or control panels. However, some browsers do not support separate dialog boxes, and even those that do allow users to disable them, so the design must also function without separate dialog boxes.

General Preference Settings

The following settings are provided in the General tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

General Open Issues

  1. Currently, the design contains a violation of the rule that the application-specific toolbar contains functions that apply to the entire content area. When a Folder View is displayed, the current plan is to include buttons on the function-specific (bottom) toolbar for replying to selected messages, forwarding them, deleting them, moving them, etc. (in addition to the pop-up menu of applicable functions that is on each item's type-icon). However, these are actually operations on specific objects in the content area. Thus, according to our design rule, the buttons for these functions should be in the content area, near the items. However, that doesn't seem practical in this case. One solution is to ignore the inconsistency. Another solution is to eliminate these buttons and supply their functions via a pop-up menu that is under each item's type-icon. A third solution is to place controls that apply to messages in the content area, e.g., on each message line (ugh!). Decision: Unless it proves to be a problem (e.g., in usability testing), we have decided to ignore this issue.
  2. Throughout the design, text fields for specifying arguments are augmented with buttons that bring up the appropriate sort of chooser/browser/picker/searcher: filechoosers, folder pickers, date pickers, directory lookup. Buttons that invoke filechoosers are part of a combined textfield-chooserbutton widget, and are pre-determined by the UI toolkit: they are labeled "Browse..." and we cannot change them. The issue is whether other buttons that invoke choosers or browsers should have the same label or a more specific label. E.g., buttons that invoke Directory Lookup might be labeled "Lookup". Tentative Decision: Use specific labels for each type of chooser/browser button.
  3. Is the Messaging Home Page setting restricted to which folder to show first, or should it be settable to other Messaging pages (e.g., Message Compose)? If the latter, the control will have to be more complicated than a Folder Picker. Tentative decision: Folders.

Specific Component Designs

The bulk of this specification consists of detailed specifications for the design of each functional component of the Messaging application. It also contains unresolved (open) design issues. [Back to Top]


Strictly speaking, MyPage is a separate Jupiter application, external to Messaging. However, MyPage can optionally display information from Messaging, so it needs to be discussed in this specification.

MyPage can (optionally) include a section listing the contents of the user's Inbox. This section looks and behaves similarly to the Messaging Folder View (see below). However, the Inbox section of MyPage is not a fully functional Folder View. It displays abbreviated information and provides limited functionality. It mainly allows users to see their messages, open them, and view them. Whether the messages shown are just new messages, or all messages in the Inbox, depends on a Preference setting, for which the default is "new messages only".

Because there is limited space on My Page, the number of Inbox messages listed on My Page is restricted to some a specified maximum number (specified in Preferences; defaults to 10). Let's call that number N. If the number of messages to list is greater than that, buttons or links are provided (on the header for the Messaging section of My Page) for displaying the next and previous N messages, as in most Web search sites. The display also indicates which set of N is currently being displayed.

As in Folder View, when a user moves the mouse-pointer over a message item and holds it there, a popup window will appear that shows more of the contents of the message. This gives users a quick way to see some of the contents of the message without actually opening it.

The proposed appearance of MyPage (including a Messaging section) is illustrated in Figure 3.

Functions for replying to and forwarding messages will not be available directly in MyPage. To reply to or forward a message displayed in the Messaging sub-component of MyPage, users will have to first open the message, which takes them to the Message View function, where Reply and Forward functions are provided (see below).

Function-Specific Commands

When MyPage is displayed, and includes a Messaging section (i.e., a view of the Inbox), the titlebar for the section contains an iconic button that invokes the "Fetch New Mail" function.

MyPage User Preference Settings

Because MyPage is a separate application from Messaging, many of its preferences will be set in the MyPage preferences. In particular, the controls to customize which application-sections are displayed on MyPage are on the MyPage tab-panel of the Jupiter Preferences; they are not Messaging Preferences.

In any case, the Messaging-related MyPage preference settings are (not necessarily in this order or with these labels):

My Page Open Design Issues

The following open design issues pertaining to MyPage remain to be resolved:

  1. Does the Fetch New Mail button switch to the Messaging Inbox page or remain on MyPage? Tentative decision: Remain on MyPage.
  2. Does My Page have a bottom buttonbar? Tentative Decision: No. [Note: Because My Page isn't a part of Messaging, this issue is really outside the scope of this specification.]

Folder View

Email messages in Jupiter are contained in a hierarchy of mail folders. The hierarchy consists of a root folder at the top (called the 'Top' folder), a set of built-in folders (with unchangeable names) that are contained directly in the root, and a hierarchy of user-defined folders below certain built-in folders. The user interface that allows users to look at and manipulate a mail-folder's content is called Folder View.

Mail Folder Hierarchy

The top-level folder in the hierarchy of mail folders is named 'Top'. This name cannot be changed.

The built-in folders in the Top folder are: Inbox, Drafts, Trash (aka Deleted), Sent, Outbox, My (private) Templates, Public Templates, My (private) Folders, and Public Folders. The names of these folders cannot be changed. Jupiter Messaging provides always-available buttons that open each of these built-in folders.

Most of the built-in mail folders (Inbox, Sent, Drafts, Outbox) cannot contain sub-folders. The Trash folder can contain sub-folders, but users cannot explicitly add arbitrary sub-folders. The Trash folder can contain only sub-folders that users deleted from their mail folder hierarchy.

The built-in folder called 'My Folders' may contain whatever sub-folders the user desires, and in fact will typically be the root of an entire sub-hierarchy of user-defined folders to it. Messaging provides functions for creating, naming, deleting, moving, and copying folders under the My Folders folder hierarchy, and for storing messages in them.

The built-in folder labeled 'Public Folders' is the root of the entire hierarchy of public and shared email folders that exists on the customer's organizational network. However, Jupiter Messaging does not provide facilities for creating and managing shared and public mail folders (i.e., those under the 'Public Folders' built-in folder). Such folders are created and managed by administrators using software other than Jupiter. Jupiter only provides facilities for viewing, navigating, and adding messages to such folders.

The built-in folder called 'My Templates' can contain template folders saved by the user. It will come pre-stocked with a few templates to help users get started. All templates created and saved by the user will be saved here. This folder may not contain sub-folders.

The built-in folder called 'Public Templates' holds public templates. However, Jupiter Messaging does not provide facilities for saving public email templates (i.e., in the 'Public Templates' built-in folder). Public templates are stored in the public templates folder by administrators using software other than Jupiter. Jupiter only provides facilities for viewing such templates and creating messages from them.

The hierarchy of folders in Jupiter Messaging is illustrated in Figure 4.

The hierarchy of folders in Jupiter Messaging.

Figure 4: Jupiter Messaging Email Folder Hierarchy.

Folder View Listings

When Messaging is displaying the contents of a mail folder, the content area will be divided into three areas: a top line displaying the directory path to the current folder, an area optionally displaying any sub-folders of the current folder, and the main area listing the messages in the current folder (see Figure 5). These three areas are now described further.

Folder View Content Items

Mail folders can contain messages and sub-folders (with some exceptions among the built-in folders). When the contents of a mail folder are displayed, each item appears as a line in a scrolling list of items. From left to right, each item-line contains:

The icon for each item listed in Folder View has a pop-up menu of actions that apply to the item. The contents of the menu would depend on the type of item (e.g., folder vs. message, type of folder, type of message), and are functions that are expected to be used frequently. The functions in these menus are a subset of the union of the functions provided on the bottom buttonbars of the Folder View and Message View pages.

Folder View Navigation

The Folder View provides four ways for users to navigate between mail folders:

Folder View Bottom Buttonbar Commands

When viewing the contents of a mail folder, the following command buttons will be provided in the function-specific (bottom) toolbar:

Both the Copy and Move operations check that the indicated destination folder is a valid destination for the to-be-transfered items. The Trash, Drafts, and Templates folders don't accept explicit Copy or Move operations (i.e., other operations are used to move items into them them, e.g., Delete, Save as Draft, Save as Template). Shared Folders only accept messages from approved users. Only the users My Folders hierarchy accepts Moved or Copied sub-folders. If the destination folder can't accept the selected items, an error dialog box appears describing the reason for the rejection.

The selection check-boxes on folder items allow multiple-item selections for commands that can apply to multiple items (e.g., Delete, Copy, Move, Forward). The Reply and Reply All functions check for multiple selections and display an error dialog box reading:

More than one message is selected.
You may only Reply to one message at a time.
Please select just one message and click Reply again.

The Forward, Reply, and Reply All functions check that the selected items are messages and not folders. If the selected items are folders, these commands check display an error dialog box reading:

A folder is selected
You may only {forward | reply to} messages, not folders.
Please select a message and click Reply again.

The Delete, Copy, Move, Accept, and Decline functions optionally provide acknowledgement of the completion of the operation. They display a dialog box informing the user about what happened (e.g., the number of items deleted, copied, moved, and where they were put). For each function, a Preference setting is provided to allow users to enable and disable the acknowledgements.

View Preference Settings

The following settings are provided in the Folder View tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Folder View Open Design Issues

The following open design issues pertaining to Mail Folders remain to be resolved:

  1. Will the sub-folder list have column headers? Tentative decision: Yes.
  2. How will shared folders be distinguished from public folders in folder listings? They are both in the 'Public Folders' hierarchy. E.g., do they have different icons, or do they have a separate marking or meta-data? If they have a different icon, what will it be? Icon is The graphic designer's decision; meta-data is development's decision.
  3. Where will the button for opening and closing the sub-folder list be placed? In the content area? On the folder-path line? The graphic designer's decision.
  4. What is the symbol for Urgent and Low-Priority messages? Idea: red up-arrows (or '^') for Urgent and black down-arrows (or v') for Low Priority. The graphic designer's decision.
  5. Is there a way for users to set, while looking at the contents of a folder, the number of messages listed at a time, or is this only settable in the Messaging Preferences? Tentative decision: Only in Preferences.
  6. Date and Time format will be determined at installation and also can be set globally for Jupiter in the Preferences. Should it be possible for users to separately set the format for times and dates that are displayed as meta-data on messages, folders, and attachments? Tentative decision: No.
  7. When Folder View is active, what will be displayed after the word 'Messaging' above the Application-specific toolbar? 'Folder View' seems too implementation-centric. An alternative is to consider Folder View to be Messaging's 'main' function, and so have its name be blank. Thus, when Folder View is active, the application-title line would just read 'Messaging'. Tentative decision: Folder View name is blank.
  8. Displaying the folder path purely textually requires finding a suitable separator character that suggests hierarchy but doesn't seem too computer-geeky. An alternative approach is to display the folder path as a row of buttons. This eliminates the need for a character separator. Another alternative: use a folder icon as a separator, as in Motif's file manager. The graphic designer's decision.
  9. Copy and Move may not be able to use the Folder Picker popup, because it may not be feasible to implement it. In that case, it may be necessary to place a Folder Picker drop-down menu near the Copy and Move buttons.
  10. Given that the limitations of web-applications requires that only a specified number of messages be listed in at a time, we need to provide an indication of which 'page' of messages the user is currently viewing (as well as buttons to switch to the next and previous 'page'). Two choices (with pros and cons):
    1. 'Page N of M'. Pros: compact, fixed length. Cons: user can't navigate directly to a given 'page', possible confusion between use of 'page' for web-page vs. page of messages.
    2. List of 'page' numbers, where each number is a button or link that takes the user to that 'page'. Pros: User can navigate directly to pages, avoids using the word 'page'. Cons: unknown maximum length: if a folder contains a very large number of messages, we may need to show only 10 pages at a time and provide a paging mechanism for the paging mechanism (i.e., buttons to list next and previous group of 10 pages), which seems overly convoluted.

Folder Picker

The Folder Picker is used in a variety of contexts in Jupiter Messaging to choose an email folder. Examples include: navigating through the email folder hierarchy, choosing a destination for a message Move or Copy operation, and specifying where to conduct a Search for a message.

The Folder Picker is essentially a menu of all email folders in the system (public and private), displayed as one list. Because the menu will normally contain many folders, it will be scrollable. Sub-folders will be indented to show their hierarchical relationship, but it will not be a fully-functional tree-widget, i.e., users cannot expand or contract particular folders, or drag-and-drop folders.

The Folder Picker is provided in two different forms depending on the context and browser limitations:

Folder Picker Open Design Issues

The following open design issues pertaining to Folder Picker remain to be resolved:

  1. The Folder Picker popup may not be possible for the first release. Functions currently spec'd to use it may have to get by with the Folder Picker drop-down menu, which means that a menu will have to be placed wherever it is needed. Tentative decision: Try to implement Folder Picker popup.
  2. Most functions that use the Folder Picker (e.g., Go To, Move, Copy) display the Folder Picker popup as part of the sequence of executing the command. But the Detailed Message Search function (see below) operates differently: the user first invokes the function, the search-parameter settings appear (include the Folder-to-search setting -- a Folder Picker drop-down menu), and then the user clicks on the Search button). This inconsistency may be a problem for users. Tentative decision: Leave it for now and check in user-testing.

Message Compose

The Message Compose facility allows users to prepare email messages for sending. This includes creating original messages, editing draft messages, creating messages from stored templates, replying to received messages, and forwarding received messages. The Message Compose facility underlies all of these activities, and operates similarly for all of them. However, slightly different functions will be available for these somewhat different situations.

Message Compose function can be invoked from outside the Messaging application as well as from within it. For example, Jupiter provides a Create Message command that is always available, regardless of which Jupiter application is being used. When Create Message is invoked while the user is in applications other than Messaging (e.g., Calendar, MyPage), Jupiter switches (temporarily) to the Messaging application (and changes the display accordingly), but when the message has been created, returns to the context the user started in.

The Message Compose page of Jupiter splits the application-content area into an upper and a lower sub-area:

We first describe the upper part of the Message Compose page (headers), then the tab-panels of the lower part, then the functions on the toolbar that apply to the entire Message Compose page. Figures 6-8 illustrate the Compose-window's tab-panels.

Message Compose Header Area

As described above, the header area of the Message Compose page always shows a subset of all possible headers (initially To, CC, and Subject fields, but customizable by users), and shows additional headers on request. When a user clicks on a button labeled 'Show All Headers', the middle of the page expands to show additional headers that users can set, pushing the tabbed lower area (message text, attachments, options) downward.

Also in the upper area is a drop-down menu or radiobutton set to allow users to set the message priority: Normal (the default), Urgent, and Low.

When users are composing email messages, they will naturally want to lookup email addresses of intended recipients for inclusion in the various address fields. The header area of the Message Compose page provides access to the Directory Lookup function (which allows users to find addresses of people in their Jupiter Buddy List, in their Address Book, in the Organization Directory, and even on the Web. To invoke the Directory Lookup function, users click on links that are on the labels 'To:', 'Cc:', 'Bcc:', etc. Regardless of which one of these links a user clicks on, the same Directory Lookup window is invoked, albeit with different default assumptions about which address-field in the message the looked-up addresses will be placed into. See the section of this specification on the Directory Lookup function for more details.

Message Compose 'Message Text' Tab-Panel

The Message Text tab-panel (see Figure 6) contains a large scrolling text area into which the user types the body of the message. Normal text-editing capabilities are available in this text area. The length of the text area is set in the Messaging Preferences; it does not grow as the browser window is stretched. It is initialized to a length that fits entirely on screen without scrolling, but this length is likely to be annoyingly short for some users. However, lengthening it will cause the text area to extend below the bottom of the content-area, requiring users to scroll the content area to see the entire text area, and then perhaps having to scroll the text area separately to see text within it. This cannot be helped because of the constraints imposed by Jupiter's being a web application that runs inside a browser.

When the Message Compose function is invoked to reply to a received message (i.e., via the Reply or Reply All commands), it can be set to appear with the previous message either 'quoted' in the text area (i.e., each line will begin with a user-settable quote character, e.g., '>') or not 'quoted' depending on the Messaging Preference settings. Even if the message is quoted in the reply, it can be deleted (like any other text) by selecting it and either pressing Delete or by simply typing something else. An 'Include Original Message' button is provided (above the text area) to allow users to insert -- at any time while they are composing a reply -- a quoted copy of the message being replied to. This button is present, but inactive, in composed messages that are not replies.

When the Message Compose function is invoked to forward a received message (i.e., via the Forward command), the original message appears 'quoted' in the text area. The insertion point is positioned at the beginning of the message area, to allow the user to add his/her own message in front of the forwarded one.

Message Compose 'Attachments' Tab-Panel

The Attachments tab-panel (see Figure 7) is for adding attachments to a message that one is preparing to send. It also allows users to delete attachments and to copy attachments from a message that is being forwarded or replied to. These functions are provided via buttons that are present on the tab-panel itself (since they are specific to it). The buttons on the Attachments tab-panel are: Add..., Add Attachments from Original (for Replies and Forwards only), Delete, Delete All.

The Attachments tab-panel displays a scrolling list of attachments that is similar to a Folder View: it lists attached documents. Users may add attachments by pressing the Add... button. It brings up an 'Attach File' dialog box (or web page) that contains a text field labeled 'Filename' with an adjacent 'Browse...' button (and the standard OK and Cancel buttons at the bottom). Users put the attachment's file pathname into the Filename field in either of two ways: a) typing it there, or b) clicking the 'Browse...' button to bring up a filechooser (a separate dialog from the 'Attach File' dialog) to allow them to browse their local file hierarchy to locate a file, then clicking on the filechooser's OK button. However the Filename field is filled, clicking on the 'Attach File' dialog box's 'OK' button inserts the indicated file into the attachments list. [Note: The Attachments list in a message is a list of arbitrary files, not a list of email messages. It therefore should look more like how documents are listed in Jupiter Document Management folders, rather than like how email messages are listed in Jupiter Messaging folders. However, Document Management is not yet designed, and won't be for some time, so the Attachments list will initially be based on Messaging's Folder View.]

When a message is being composed based upon a previously received message (via Reply, Reply All, or Forward), the attachments that were in the received message are included in the new message or not, depending on the users Messaging Preference settings. If the attachments were included and the user does not want to send them with the new message, the user can delete the attachments, either individually, by selecting an attachment in the list and clicking on the Delete button, or all at once, by clicking on the Delete All button. When a message is a Reply or a Forward of a received message, the Message Compose window will include a button on the Attachments tab page that adds the attachments from the original message to the new message.

Message Compose 'Options' Tab-Panel

The following options can be set for email messages that are being prepared for sending. The setting labels given here are intended to be self-explanatory for the purposes of this document. They are not necessarily the actual labels that will be used in the software. See Figure 8 for the proposed layout and actual labels of the Option settings.

Message Compose Bottom Buttonbar Commands

When a message is being composed, the function-specific (bottom) toolbar contains buttons that apply to a composed message:

Message Compose Preference Settings

The following settings are provided in the Message Compose tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Message Compose Open Design Issues

The following open design issues pertaining to Message Compose remain to be resolved:

  1. Placing the tab-panels for the message text, attachments, and options below the message headers leaves little space for the message text, which is arguably the most important part. An alternative design is not to split the display into headers vs. other info, but rather to put the tabs on top of the application-specific toolbar and include the headers in the 'message text' tab. This leaves more space for the message text area. However, it also has disadvantages: a) the application-specific toolbar is inside the tab-panels, even though that toolbar is constant throughout Messaging and thus isn't logically in the tab-panels, b) putting the headers on the message means that the headers are not visible when the attachments or options tab panel is selected, and c) putting the headers on the message means that there is less room for the message text than for attachments or options, which seems like the wrong allocation of space.
  2. Will the Attachments list look similar to a FolderView list, or will it be just a simple scrolling list control, with only each attachment's name shown? If the FolderView approach is taken, what data will be shown for each attachment, and is this user-customizable (as it is with messages in folders)? Ideally, this list should look like a Document Management folder view, not a Message folder view, because attachments are documents, not messages. Tentative decision: scrolling list widget.
  3. The design calls for different content-specific functions to be provided depending on whether a message is being composed as an original message, a reply, or a forward. Should the Message Compose design always provide the same command-buttons in the content area but activate relevant ones in each of the above three situations, or should buttons that are not needed in the current type of message composition be entirely absent? Tentative decision: Absent.
  4. In the Message tab-panel, it may not be possible to implement an 'Add...' button that brings up a filechooser for specifying the attachment to add to the Attachments list. We may instead have to have a textfield with a 'Browse...' button, and a separate Add button that takes the file pathname from the textfield and adds that file to the Attachments list.

Message View

When a user views the contents of an email message s/he has received, it is through the Message View facility. The Message View function, like the Message Compose function, displays several different aspects of the content of a message: headers, message text, attachments, and options. The Message View presentation is similar -- but not identical -- to that of the Message Compose function. It is similar in that the overall structure is the same: an upper area that shows the headers and priority, and a lower area with three overlapping tab-panels for Message Text, Attachments, and Options. Message View differs from Message Compose in that the information in each of these areas and tab-panels differs slightly and is mostly not editable. Figure 9 illustrates the Message View page.

Message View Header Area

The header area normally displays the same headers as are normally displayed on the Message Compose page: To, CC, and Subject. In addition, the Message View header area also normally shows fields that were generated by the sender's mail software: From, and Date & Time. The header order is: From, Subject, Date & Time, To, and CC. In the first release of Messaging, the headers normally shown and their order is not customizable by users.

As in Message Compose, the remaining headers can be displayed by clicking on a button labeled 'Show All Headers', which pushes the tab-panels downward to make room for the headers. Of course, the headers shown in Message View can be quite long, since they include all the system-generated headers that indicate the message's path from the sender to the recipient.

When showing a message that is an Invitation, the headers shown will be those that are relevant to an Invitation: When, Where, etc.

Header fields are shown as plain text on the background, not as text fields (i.e., not even as non-editable text fields). If headers are longer than can be shown on one line, they will be wrapped up to a reasonable number of lines (e.g., 2) and then truncated (with '...' indicating the truncation). In such cases, the entire header can be viewed via a rollover popup.

The Message Priority is displayed in this area as an icon. It is not editable.

Message View 'Message Text' Tab-Panel

The text of received messages cannot be edited. (Of course, when a user forwards a received message or replies to it and includes it as a quoted message in the reply, what was a received message becomes a message to be sent, which is handled by the Message Compose facility and is therefore editable.)

The text of the received message is displayed as text on a white background, not in a scrolling editable text area. When it is too long to be displayed fit on the screen, it will simply extend down the page, like any long Web page. In this case, users can read it by scrolling down.

Message View 'Attachments' Tab-Panel

The 'Attachment' tab-panel is identical to that of the Message Compose function, except that the only function available is 'Save As...', which displays a 'Save Attachment' dialog box (or web page) that contains a text field labeled 'Filename' with an adjacent 'Browse...' button (and the standard OK and Cancel buttons at the bottom). Users put the destination file pathname into the Filename field in either of two ways: a) typing it there, or b) clicking the 'Browse...' button to bring up a filechooser (a separate dialog from the 'Save Attachment' dialog) to allow them to browse their local file hierarchy to locate a file, then clicking on the filechooser's OK button. However the Filename field is filled, clicking on the 'Save Attachment' dialog box's 'OK' button saves the attachments in the indicated file-location.

Message View 'Options' Tab-Panel

The Options tab-panel is provided mainly to allow message recipients to see what options the sender set. It is similar to the Options tab-panel of Message Compose, except that the settings are not editable: they are displayed as inactive, i.e., greyed out. [Note: We may want to include the Priority setting here, and make it editable; see above.]

Message View Bottom Buttonbar Commands:

When viewing a message, the following command buttons will be provided on the function-specific (bottom) buttonbar:

Message View Preference Settings

The following settings are provided in the Message View tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Message View Open Design Issues

The following open design issues pertaining to Message View remain to be resolved:

  1. Split content area into headers vs text, attachments, and options as with Message Compose, or move tabs to the top? The choices are to make Message View look very similar to Message Compose, or make it look very different. E.g., an alternative to displaying headers of received messages above the message tab-panel is to eliminate the upper 'header' area (i.e., diverge from the Message Compose display) and display headers in the message text area, as some mail-clients do. An even more radical design is to eliminate the tab-panels for attachments and options, and display attachments and option settings as message headers. Tentative decision: Try for separate tab-panels, but backup plan is that everything is in the message body and attachments and options are shown as headers.
  2. Will we provide a Message Details display (as in OfficeComm Windows client) that shows potentially useful details about a message? E.g., When received, size. Or should this info be provided in the additional headers? Tentative decision: Not in Message View. Maybe a rollover popup in Folder View.
  3. The design calls for different content-specific functions to be provided depending on the type of the message being viewed, e.g., regular vs. invitation. Should the Message View design always provide the same command-buttons in the content area but activate relevant ones depending on the message-type, or should buttons that are not needed for the current type of message be entirely absent? Tentative decision: Absent.
  4. Should the default headers include Sender, From, or Reply-to? Probably only one of these is needed, but which one? Tentative decision: Provide 'From' if available. If not, provide 'Sender' if available. If not, provide 'Reply-to'.

Address Book

The Address Book is each users' private collection of email addresses. In it, users can create and save email address information for individuals and private email distribution lists. Each entry in the Address book associates a name with an email address. Users can also define abbreviations for Address Book items, allowing them to use those abbreviations when addressing messages.

Unlike some email clients, but like previous SageBrush email clients, the Jupiter Messaging Address Book distinguishes between aliases for individuals and email distribution lists.

Because items in the Address Book are stored by name, no two items may have the exact same name. Even if one item is an individual and another is a list, they must still have different names.

The Address Book contains only email address information, at least in the first release. It is not a general-purpose address book. It does not contain phone numbers, mailstops, home phone numbers, birthdays, etc.

Each user has only one Address Book, the unchangeable name of which is 'Address Book'. Unlike some email clients, Jupiter Messaging users cannot create special-purpose, custom-named address books.

The Address Book display consists of the content area and the bottom buttonbar commands (see Figures 10 and 11).

Address Book Content Area

The Address Book content area consists of a control panel that is visibly divided into a left and a right side.

On the left side of the Address Book panel is a scrolling HTML frame listing individuals and lists. Each item in the list consists of an icon that identifies the type of item (individual or list), followed by the item's full name. Each Address Book item in the list has a checkbox to allow it to be selected for certain subsequent operation s, e.g., Delete. Items are listed in alphabetical order by their full name; users cannot change the order.

Each Address Book item's name is displayed as a hypertext link. Clicking on the link displays the definition of that entry in the right side of the panel. Clicking on the link also checks that item's checkbox to mark it as 'selected', and unchecks the checkboxes of all other items. Moving the mouse pointer over an Address Book entry's name and holding it there displays a popup window showing the item's abbreviation if the user assigned one.

On the right side of the panel are datafields for entering and editing the information that defines the currently selected Address Book item, if any. When a user chooses an Address Book item or creates a new one, the corresponding data form appears on the right side and the data is treated as 'connected to' the item until another Address Book item is chosen or a new one is created. If no item in the Address Book list has been clicked or created, the right side of the panel is blank. [Note: This is partly because it is not clear which of the two forms to show in this case, and partly to prevent users from entering data and attempting to Save when there is no associated Address Book item.]

The form for Individuals differs from the one for Email Lists, and so the form on the right side of the panel (and the data in the form) depends on which Address Book item the user last clicked, or which Create button the user last clicked (see below). However, the two forms are similar in that they have mostly the same datafields. The datafields are:

In addition to the datafields, both versions of the form contain the following button:

In the Individual version of the form, the Lookup button is next to the Email Address datafield. In the List version of the form, the Lookup button is next to the Address List control.

In the List version of the form, two content-specific buttons are in the body of the form, between Email Address field and Email List field:

The bottom buttonbar is divided into left and right sections. The left section contains functions that pertain to the left half of the control panel, i.e., the Address Book list:

The right section of the bottom buttonbar contains functions that pertain to the right half of the control panel, i.e., the Address Book item data form:

When the Save button is clicked, the Address Book first checks that the supplied data is sufficient to allow the Address Book item to be used (Individual: name and email address; List: name and address list). If any of these is missing, an error dialog box appears indicating what is missing:

<Individual, List> Address Book item has no <name, email address, addresses in the address list>. Do you want to Save it anyway?
[OK] [Cancel]

If the user clicks OK, Address Book updates the information anyway. If the user clicks Cancel, the Save operation is canceled and the display returns to the state it was in before Save was clicked.

Users change the name of an Address Book item simply by choosing it from the Address Book list, editing its name, and clicking Save. Because the information displayed in the forms on the right side of the Address Book panel is always 'connected' to an item in the Address Book item-list on the left side (even if that item is a newly-created one), it is not possible for the user to be saving an item that does not exist in the list.

Address Book Bottom Buttonbar Commands

While the Address Book function is active, the bottom buttonbar will be split into two sections: left and right. The buttons in each section will be:

Address Book Preference Settings

The following settings are provided in the Address Book tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Address Book Open Design Issues

The following open design issues pertaining to Address Book remain to be resolved:

  1. In the current design, user-defined aliases for public email lists are treated differently than are user-defined email lists. Specifically, the Address Book treats aliases for public lists as 'individuals', not as lists. That is, if a user finds an address for a public list and wants to include it in his/her Address Book (perhaps under an abbreviated name), s/he would do so by adding an Individual, not List. This will probably confuse users. If so, we may want to add a third kind of Address Book item to clarify matters: List Alias.

  2. There are two different kinds of 'selection' for Address Book items: a) clicking on the item to display or edit its data, with an indication of which item is the current one, and b) checking an item's checkbox so it can be deleted. In the current design, these two types of selection are unified: clicking on an Address Book item also turns its 'selection' checkbox on to indicate which item's data is being shown. But other lists in Messaging that have checkboxes on each item don't unify selection in this way. Should they? If not, will the inconsistency be a problem for users? If we decide not to have clicking on an item also turn on its checkbox, we'll need some other way to indicate which item is the current one.

  3. In the current design, there is a difference between Individual form and the List dataform in the meaning of the Email Address data field. In the Individual form, the Email Address is part of the definition of the Address Book item. It is also what gets filled in when the user invokes Directory Lookup. In the List form, the Email Address field is not part of the definition of the Address Book item. It is only a place for a user to type an address to be added to the Address List (using the Add button). Its content (if any) is ignored when the List is Saved. It also does not get filled in when the user does a Directory Lookup; Directory Lookup adds items to the Address List. The alternative is to have the Directory Lookup dump its results into the Email Address field in the List form as well as in the Individual form, but the consequence of doing that is that users would have to look up items one at a time to add to the Address List.

  4. What is the maximum length of a Name for an Address Book entry? Ditto the Abbreviation? Ditto the Description? TBD.

  5. Do we need a 'Done' button on the bottom buttonbar in Address Book? We don't have one in Folder View. Tentative decision: No.

Directory Lookup

The Directory Lookup function allows users to lookup email addresses (and, eventually, other information) for various purposes. Directory Lookup is somewhat different from the other Messaging functions, because it isn't a stand-alone function, but rather is always used in the service of some other function. There are many situations in Jupiter Messaging -- indeed, throughout Jupiter -- where users might need or want to look up a user ID, an email address, or other information about an person, organization, mail list, or shared resource (e.g., a room or a piece of equipment). Such situations include: preparing an email message to send, setting access permissions on a folder, listing the intended participants in a meeting, reserving a room or a piece of equipment.

The Directory Lookup function provides facilities for finding information in the Buddies list, Address Book, organization directory, and on the World-Wide-Web. In some situations where it is available, links are provided to invoke it (e.g., on the various address labels in the Message Compose function). In other situations, specific buttons invoke it (e.g., the 'Lookup...' button on the Email Address field in the Address Book).

The user-interface to the Directory Lookup is similar across the contexts in which it is used (see Figures 12-14). If the user's browser allows, the Directory Lookup controls will be displayed in a separate dialog box; otherwise, they will be displayed by switching the user's browser to a web page (saving the previous page so it can be returned to). The Directory Lookup provides menus and textfields to allow users to specify which of the following information repositories they wish to search: the user's Buddy List, the user's Address Book, the organization directory, and the World Wide Web. To execute a search, a user must specify:

Once a search has completed, the results are displayed in a scrolling HTML frame positioned on the left side of the screen below the search-parameter settings. The results list looks similar to the results of Web search-engines: it displays a pre-specified (user settable) number (call it N) of found items and provides controls for displaying the next and previous N found items. Each item in the results list begins with a checkbox to allow it to be selected for transfer to the function for which Directory Lookup was invoked.

The controls for determining what to do with found addresses are on the right side of the panel. They are similar across situations, but differ in their details depending on the requirements of the situation. Three variations of these controls are provided. The first variation is specialized for composing email messages; the other two variations are generic: one for choosing multiple addresses, one for choosing a single address. The three variations are:

When the user clicks OK (see below), the Messaging transfers the data associated with the chosen found items to the calling context. [Note: The data related for each chosen found item is more than just the text of the name or address. When Directory Lookup is invoked from Address Book, for example, both the name and the address need to be returned. When Directory Lookup is invoked from Message Compose, the address would suffice, but most modern email clients display the full name, rather than the address, in the message's address field, even though the message is actually sent to the address.]

Directory Lookup Bottom Buttonbar Commands (actually, buttons at bottom of dialog box)

While the Directory Lookup function is active, the following command buttons will be provided in the center area of the application-specific toolbar:

Directory Lookup Preference Settings

The following settings are provided in the Directory Lookup tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Directory Lookup Open Design Issues

The following open design issues pertaining to Directory remain to be resolved:

Message Templates

Message templates speed creation of email messages. They are partially-completed messages that users save to help them create specific types of messages: invitations, birthday announcements, company news, etc. They contain user-specified text, and blanks that the user will fill in when a message is created from the template.

Message templates are stored in the Messaging folder hierarchy. From a user's point of view, there are two Template folders: one for the user's private email templates (called 'My Templates') and one that is the users 'portal' onto the public templates (called 'Public Templates'). Neither template folder may contain sub-folders. Both folders will be under the 'Top' folder, and thus will be peers of Inbox, Outbox, etc.

As specified for Folder View, when Templates are listed (in the two Template folders), each listed template will have a template icon. As with folder and message icons in Folder View, the template icon will have an rollover popup menu of functions that are appropriate for templates, e.g., most of those that are appropriate for messages, plus Compose Mail from Template (equivalent to clicking on the Template name) and some others (see below).

Templates can have pre-specified recipients, attachments, and option-settings.

The only way to add new Templates is to save an email message as a Template. Moving or copying a message into the My Template folder. is not allowed; attempting to do so displays an error dialog box reading:

Ordinary messages cannot be stored in the Templates folder.
To save a message as an email Template, create a new message containing the desired text, then click the 'Save as Template' button.

Templates require a Name and (optionally) a Description in addition to the message attributes. When a user clicks on 'Save as Template', a dialog box is displayed prompting the user for a Name and a Description. In addition to user-supplied Name and Description, Templates have three other attributes, which are set by the system: Create Date, Modified Date, and Size.

Users create messages from Templates (other than the default Template) by opening one of the Template folders and clicking on one of the Templates. Users edit Templates by the same method, but when done editing they click Save as Template again instead of Send, at which point the dialog box containing the Template data is displayed to allow the user to change the Template Name and/or Description.

There is no way to view Templates without editing them, i.e., invoke Message View instead of Message Compose.

By setting Compose Mail and Mail Handling preferences, users can assign templates to be used to create new original messages, to reply automatically to incoming mail, and to automatically forward incoming mail. To allow users to assign templates to these roles directly from the Templates folder (i.e., without having to go into the Preferences application), each Template's icon rollover popup includes the following functions, which assign the corresponding Template to the indicated role:

If another template is already assigned to one of the above roles, a dialog box appears:

Replace <other template name> as the <Default Message | Auto Reply | Auto Forward> template?
[OK] [Cancel]

If no other template is already assigned to the given role, or the user responds 'OK' to the above dialog box, the template is assigned to the indicated role.

In the first release, signature files are not supported as a distinguished type of Template. The default Template can of course contain signature text. However, if a user chooses a Template that does not include a signature, no signature will be appended.

Message Templates Preference Settings

The Message Templates facility has no explicit user preference settings of its own. Some preference settings for other Messaging facilities (e.g., Message Compose, Automatic Mail Handling) require the specification of templates, but those preference settings are provided in the appropriate section. For the reader's convenience, those user preferences that use Templates are listed together here:

Message Templates Open Design Issues

The following open design issues pertaining to Message Templates remain to be resolved:

  1. Could we provide a kludge for signatures that allowed users to insert a designated template at the end of the message? At any time during composition? At send-time? Tentative decision: No.

  2. Do we need hierarchies of templates, especially in public templates, of which there will probably be a lot? Tentative decision: No.

  3. When a user is viewing a Template folder, could we provide a Create Template button on the bottom buttonbar to facilitate template creation? Or are the buttons that are available when viewing a Template folder just those that are available when viewing any folder? Tentative decision: No.

  4. In most email folders in Jupiter Messaging, clicking on a message displays it for viewing. However, the current design specifies that clicking on a Template (or a Draft) invokes Message Compose function. Tentative decision: Leave it for now and check in user testing whether this inconsistency is a problem for users.

Mail-Handling Rules

Mail-Handling Rules allow users to direct Jupiter Messaging to respond automatically to certain pre-specified events, such as the arrival of an email message or the user logging off.

In the first release, Jupiter Messaging will support only global simple mail-handling rules, e.g., AutoReply to all messages, AutoForward all messages, Empty Trash on logout. These will be activated or deactivated by users in the Jupiter Preferences (Messaging/Mail Handling section). More complex mail-handling rules that depend on features of the incoming message or that pertain to particular mail folders will not be provided in the first release.

Mail-Handling Preference Settings

The following settings are provided in the Templates tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Mail-Handling Open Design Issues

The following open design issues pertaining to Mail-Handling Rules remain to be resolved:

None at present.

Message Search

The Message Search function is for searching through specified mail folders to find messages that satisfy specified criteria. For example, if a user misfiled a message from a friend about something important and later needed to find it, she could search her entire private folder hierarchy for messages from that sender. To narrow the search, she could even specify that the message had to have been sent between two specified dates, or have had the word 'taxes' in the subject. As another example, suppose a public folder archiving an online discussion group contained thousands of messages, and a user wanted to quickly locate the latest one on a given discussion thread.

In the most general case, to search for messages, a user would specify the following information (not necessarily labeled this way):

However, Jupiter Messaging's Search facility won't be that general. General message search facilities can be extremely complicated. Most users need only simple search facilities most of the time.

Accordingly, Jupiter Messaging will provide two search user interfaces: a) a very simple 'Basic' Search facility and b) a somewhat more complex 'Detailed' Search facility on demand. However, even the Detailed Search facility will not be fully-general, e.g., it won't allow construction of arbitrary complex combinations of search criteria. It won't even allow specification of other sort of text-string-matches besides substring. Future versions may provide a fully general Search facility for use by the small number of users who understand such things.

The Basic and Detailed Search forms are presented as two overlapping tab-panels occupying the left side of the upper half of the Search function page. The right side of the upper half of the Search page contain settings that both search-methods share: those that determine what folders will be searched. The lower half of the page is a separate HTML frame that displays the search results (see below).

Once messages are found and listed in the Search Results, they may be copied, moved, or deleted.

Search Location

The controls that determine what folders will be searched allow users to specify that the search is to include either all folders belonging to the user (i.e., the Inbox, Outbox, Trash, Drafts, Sent, My Folder, My Templates) or a specified folder (and, optionally, all its sub-folders). The controls are:

Search in:

O All Private Folders (the default choice)

O Specified Folder: [Folder Picker drop-down menu] [] Include Sub-folders

The user specifies by clicking on radiobuttons whether they want to search all their private folders and all their sub-folders (the default choice) or through a specified folder (which can be a public folder). The Folder Picker on the 'In Folder' setting is displayed as a drop-down menu that retains state (in contrast to most Folder Pickers elsewhere in Messaging, which are displayed as iconic buttons that bring up a pop-up window). If the user chooses to search a particular folder, only one folder can be chosen to search. The checkbox to the right of the Folder Picker menu is for indicating whether the search should extend into sub-folders of the indicated folder. It is not possible to search two folders that aren't on one ancestor-line in a single search operation.

Basic Search

The Basic Search (see Figure 15) assumes that a user just wants to look through all their own personal folders for messages containing some specified text anywhere in the message (i.e., subject, body, or addresses).

The Basic Search form contains only one text field, labeled 'Search for:', and a button labeled Search. To use it, a user simply types some text into the textfield and clicks on the Search button. No date-range restriction is provided. The match is always a substring match.

Basic Search looks for matching messages in the indicated folders.

Detailed Search

Detailed Search (see Figure 16) form has several data fields; users can fill in any fields that they desire. The form fields are as follows:

Search for messages with:
Subject: <text field>
Sent After: <date field> [Date Picker] Before: <date field> [Date Picker]
Addressees: <text field> [Lookup...]
From: <text field> [Lookup...]
Message Content: <text field>

On all the datafields except the 'Subject' field, users can either type the data into the field, or choose a value using the associated Picker/Lookup buttons. The Date Pickers specified on the 'Sent After' and 'Before' fields are graphically-labeled buttons that invoke the Date Picker that was implemented for Jupiter Calendar. The Lookup buttons invoke the Directory Lookup facility (see above).

After the desired data is specified, the user initiates the search by clicking on the Search button, which is positioned just below the datafields. Any fields filled in by the user contribute to the search; any fields left blank do not. All fields are ANDed together, i.e., only messages that match all the given criteria will be included in the search results. All text matching for is substring matching. The 'Addressees' field matches substrings of addresses in any of the message's To and CC fields (and if the message was sent by this user, the BCC fields). The date comparisons are > and < comparisons.

Like Basic Search, Detailed Search looks for matching messages in the indicated folders.

Search Results

The results of a Message Search are displayed in a scrolling HTML frame below the Search criteria. The results-list looks and behaves similar to a Folder View, e.g., each item includes an icon, a message topic, a date, and other meta-data. Clicking on the title (which is marked as a link) opens the message for viewing (unless it is a Template or a Draft, in which case it is opened for composing).

If the number of messages found by the search exceeds the maximum number that are to be displayed at once (set in the Search Preferences; let's call that number N), the results-list displays N found messages and provides links or buttons for displaying the next (and previous) N, as well as an indication of which items are currently being displayed (e.g., 11-20).

Message Search Bottom Buttonbar Commands:

When the message Search facility is displayed, the following command buttons will be provided on the function-specific (bottom) buttonbar:

Message Search Preference Settings

The following settings are provided in the Message Search tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):

Message Search Open Design Issues

The following open design issues pertaining to Message Search remain to be resolved:

  1. Should the Search button for the two Search facilities be in the content area (e.g., under the datafields), or should it be on the bottom buttonbar? Tentative decision: Content area.

  2. The current design leave enough room for display of Search results without requiring users to scroll down. Is that OK? Tentative decision: Leave it and check in usability testing.

  3. Does Message Search need a Done button? Tentative decision: Yes.

  4. The development team is considering avoiding embedded tab-panels on all of Messaging's pages. That would rule out their use on the Search page for separating the Basic and the Detailed search-parameters, and so would require a different approach to separating the two search-methods. That might, in turn, require a substantially different page layout.

  5. The search results must allow users to determine where (in the heirarchy of mail folders) each message was found. This can be accomplished in one of three ways: a) including the folder path in the meta-data shown for each found item, b) showing the folder path in a separate section of the page when the user clicks on an item, c) providing a mouseover popup that shows the folder path. I recommend option c.

Messaging Preferences

The Messaging Preferences facility is for setting various options that affect the operation of Jupiter Messaging. It is invoked via the Preferences button on the top Jupiter global toolbar (see Figure 2, above). Strictly speaking, it is not a part of the Messaging application, but rather is a part of the Jupiter Preferences 'application'. Therefore, when Messaging Preferences is displayed, the Jupiter title line will read 'Preferences: Messaging'.

The Messaging Preferences page is divided into a left side and a right side. The left side is a scrolling list of the Messaging facilities that have Preference settings: Folder View, Message Compose, Message View, Address Book, Directory Lookup, Mail-Handling Rules, and Message Search. The right side of the page displays the Preference settings for the whichever item in the left list is selected. Since the sections describing each facility include the required Preference settings, they will not be described again here (since two descriptions of the same Preferences could get out of synchronization as this specification is revised). Therefore, see each section for the Preference settings it requires.

Messaging Preferences Bottom Buttonbar Commands

When the Messaging Preferences function is active, the following buttons appear in the function-specific bottom toolbar:

Messaging Preferences Open Design Issues

The following open design issues pertaining to Message Preferences remain to be resolved:

  1. Are there any 'General' Messaging Preferences, or are all the settings specific to each facility? There are certainly General Jupiter Preferences, e.g., date-format and time-format, but we are seeking Preferences that are specific to Messaging but not specific to any Messaging function.

  2. Are there Preference settings for any of the facilities that have been omitted?


The user interface for Messaging Help will be the same as that for all other Jupiter applications. In particular, it will be similar to the user interface of the existing Calendar Help facility. Therefore, the user interface for Messaging Help need not be specified here.

Messaging Task-Scenarios

In the final section of the specification, we provide some envisioned task-scenarios. These task-scenarios can be used in testing the product, and they can be used in explaining the product in the user-documentation. [Back to Top]

The following are task-scenarios of use for Jupiter Messaging that we are using to guide our design. We aim to design Jupiter Messaging such that the tasks described in these scenarios are easy to learn and to perform.

The scenarios are ordered from simple to complex.


  1. User logs into Jupiter, invokes Messaging, composes a message and sends it to one person whose email address s/he knows (and can simply type in).

  2. Same as above, but user doesn't know the recipient's email address, and so must look it up in a public directory. User also wants be notified when the recipient has read the message.

  3. User logs into Jupiter, invokes Messaging, looks at messages in Inbox, scans topics and senders, and deletes some messages without reading their content.

  4. User looks at messages in Inbox, reads one, replies to sender, and deletes message. Reply includes an attached document. Reply does not quote received message.

  5. User looks at message in Inbox, reviews its attachments, closes it, files it in a folder, and forwards it (without the attachments) to a workgroup list s/he doesn't know and so must look up in the public directory.

  6. User adds a name and email address of a person to his/her Address Book. User knows the person's name and address and so can just type it in.

  7. User returns from a company seminar and creates an informal mailing list to his/her Address Book of people who wanted to continue a discussion that began at the seminar. User tests the list and discovers that two of the addresses are invalid, so he looks up the correct ones in the company directory.

  8. User creates a short alias in his/her Address Book for a public email list.

  9. While composing a message, user looks up someone's address in Address Book, doesn't find it, looks it up in company directory, adds it to Address Book and to message, sends message.

  10. User believes s/he has misfiled a message, and so searches all folders for it.

  11. User misfiled a message from a friend about something important and later Searches her entire private folder hierarchy for messages from that person. To narrow the search, she looks for a message sent between two and three months ago with 'taxes' in the subject.

  12. User searches a public folder that archives an online discussion group about investing. The archive contains thousands of messages sent during a five-year period. The user wants to quickly locate the latest few messages about Internet-related stocks. He knows the discussion thread didn't start until January of this year.

  13. User creates a template that contains a few signature lines at the bottom and tells Jupiter to use it as the default template for original messages.

  14. User creates and saves a template for messages announcing birthdays of co-workers, then uses the template to send a birthday announcement to a public list for his work-group.

  15. User sets Messaging to automatically reply to all messages while s/he is on vacation.

  16. User customizes Messaging to not confirm message deletions and not show sub-folders.