This is a new browser window. When finished viewing, just close this window.
|
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: |
|---|
|
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] |
|---|
|
Date |
Author(s) |
Comments |
|
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.
|
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.
Figure 1: Jupiter Messaging major functional facilities and flow. (Grey components are parts of Jupiter, but not parts of Messaging.)
|
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] |
|---|
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:
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.
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.
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.
The following settings are provided in the General tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
|
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).
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.
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):
The following open design issues pertaining to MyPage remain to be resolved:
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.
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.
Figure 4: Jupiter Messaging Email Folder Hierarchy.
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.
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.
The Folder View provides four ways for users to navigate between mail folders:
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.
[OK]
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.
[OK]
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.
The following settings are provided in the Folder View tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Mail Folders remain to be resolved:
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:
The following open design issues pertaining to Folder Picker remain to be resolved:
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.
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.
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.
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.
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.
When a message is being composed, the function-specific (bottom) toolbar contains buttons that apply to a composed message:
The following settings are provided in the Message Compose tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Message Compose remain to be resolved:
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.
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.
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.
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.
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.]
When viewing a message, the following command buttons will be provided on the function-specific (bottom) buttonbar:
The following settings are provided in the Message View tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Message View remain to be resolved:
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).
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.
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:
Left:
Delete 3 Address Book entries? [OK] [Cancel]'). If user confirms the deletion, delete the selected items from the Address Book.Right:
The following settings are provided in the Address Book tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Address Book remain to be resolved:
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.]
While the Directory Lookup function is active, the following command buttons will be provided in the center area of the application-specific toolbar:
The following settings are provided in the Directory Lookup tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Directory remain to be resolved:
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.
[OK]
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.
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:
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.
The following settings are provided in the Templates tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Mail-Handling Rules remain to be resolved:
None at present.
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.
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.
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 (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.
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).
When the message Search facility is displayed, the following command buttons will be provided on the function-specific (bottom) buttonbar:
The following settings are provided in the Message Search tab-panel of Jupiter Messaging Preferences (not necessarily in this order or with these labels):
The following open design issues pertaining to Message Search remain to be resolved:
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.
When the Messaging Preferences function is active, the following buttons appear in the function-specific bottom toolbar:
The following open design issues pertaining to Message Preferences remain to be resolved:
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.
|
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.