This is a new browser window. When finished viewing, just close this window.
for
SageBrush Jupiter Messaging
Thin-Client Web-Application
Jeff Johnson, UI Wizards, Inc.
21 September 1998
|
This document is an example of a Conceptual Model (sometimes called "Conceptual Design") of a software product or service. The yellow boxes are annotations (not included in actual conceptual design documents) that explain the document's various sections. For your convenience, listed below are the annotated sections of this document.
Annotated Sections of this Document:
|
|
We start by describing the purpose of this document. [Back to Top] |
This document describes a conceptual model for Jupiter Messaging, i.e., the model of Messaging that the designers want users to understand. By using the system and reading its documentation, users build a model in their minds of how the system works. Hopefully, the model that users build in their minds (often called a user model) of the system is close to the one the designers intended. This hope has a better chance of being realized if the designers have explicitly designed a clear conceptual model beforehand.
|
This section provides an overview of the design constraints, major functional facilities, and conceptual design decisions. [Back to Top]
|
Constraints
The general user-interface approach for Jupiter Messaging application is subject to the following constraints:
- It will be web-based and will be a thin client, not a large client-side application.
- It must be well-integrated with the Jupiter MyPage and Calendar applications, which already exist.
- Messaging must be highly responsive, meaning that information must display quickly, functions must execute quickly, and users should be able to work at their desired pace. Therefore, the web-pages presented by the Messaging application must not be overly complex or graphics-intensive, the functions must be efficient and interruptable, and user-actions that require tight user-feedback loops should be implemented on the client side – i.e., not require communication with the web-server – wherever possible.
- Messaging must not deviate without good reason from how users expect email applications to work. Most email/messaging clients are similar to each other in operation, and therefore users expect such applications to operate in certain ways.
Major Facilities
The Jupiter Messaging application will consist of the following facilities:
- Folder view: facilities for viewing the contents of and navigating around in mail folders, which can contain messages and subordinate folders.
- Message composition: facilities for creating messages, whether those messages are original, replies to received messages, forwardings of received messages, or revisons of previously saved draft messages.
- Message view: facilities for viewing received messages, including attachments.
- Address book: facilities for creating, managing, browsing, and searching personalized lists of email addresses and abbreviations for them.
- Directory: facilities for searching and browsing organizational email directories.
- Help: facilities for getting information and assistance about how to use Jupiter Messaging.
- Templates: facilities for creating, editing, managing, and using stored templates for email messages.
- Rules: facilities for creating, editing, and managing rules that control automatic filing and forwarding of received email, and automatic replies to it.
- Options: facilities for setting defaults and user-preferences in Messaging.
- Message search: facilities for finding particular messages stored in mail folders.
- Folder properties: facilities for setting properties of mail folders.
The following diagram shows how the facilities are related in the sense that they require access to each other.
Conceptual Design Decisions
The conceptual model embodies the following design decisions:
- 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 info, get the desired info, 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 Compose Message window. This contrasts with a systems that requires the user to cancel the message composition, invoke the directory, look up the address, and reinvoke the compose email function.
- It seems to make sense to distinguish in the user model between received messages and to-be-sent ones, so the model does so.
- For the time being, signature files and templates are regarded in the design as the same thing. Signature files are just one type/use of templates.
- In the currently planned design, received messages cannot be edited. Of course, when a user forwards a received message or replies to it and includes it in the reply, what was a received message becomes a message to be sent, which is editable.
- Each user has only one personal Address Book, the unchangeable name of which is "Address Book". Users cannot create special-purpose, custom-named address books.
- The Address Book does not distinguish strongly between private aliases and private distribution lists. Users simply assign custom names to sets of addresses, where some of the sets have one address and others contain multiple addresses.
|
The bulk of this document consists of an analysis of all concepts that will be exposed to users of this product: objects, actions on the objects, and attributes of the objects. [Back to Top]
|
Formatting Conventions Used in this Document
The objects and actions in Jupiter Messaging have a hierarchical structure. As an aid in presenting this hierarchy as well as the relationships between actions and objects, the following typographical conventions are followed:
- Objects are capitalized and italicized, and are indented according to their type/subtype or containment hierarchy. Two actual hierarchies (type/subtype and containment) are represented in a single indented structure, but which one is operative for a given action is usually clear from context.
- Actions for each object are not capitalized, and are marked with "-".
- Actions on parent object-classes are inherited by subordinate objects.
- Multiple proposed terms for an object or action are listed separated by commas.
Following the Object-Action Analysis are Notes and Issues about it.
Objects and Actions for Jupiter Messaging
- Jupiter
- - start
- - stop, quit, exit, dismiss, logout
- - login
- - set options
- - set login options
- - set password
- - set time zone
- - set print options
- - set ui options
- - retrieve new messages
- - setup global mail handling
- - setup autoforwarding of messages
- - setup autoreply to messages, e.g., vacation
- - setup rule-based mail handling [Issue: Are these app settings or folder settings?]
- - setup autoforwarding of messages
- - setup autoreply to messages
- - setup autofiling of messages
- EmailApp
- - start, invoke
- - stop, quit, exit, dismiss
- Jupiter Help Facility (Email section)
- - browse
- - start, invoke
- - stop, quit, exit, dismiss
- Spellchecker
- - start, invoke
- - stop, quit, exit, dismiss
- Spellchecker Dictionery
- - add word
- Message
- - open
- - print
- - delete
- - copy text from
- Message-to-Send
- - create
- - attach file
- - detach file
- - detach all files
- - set send properties
- - send
- - delete, cancel
- - specify recipients
- - specify subject
- - specify priority
- - type/edit content
- - copy text to
- - proofread
- Received Message
- - forward (converts received message into message to send)
- - reply
- - to sender (default)
- - do not include original message
- - include original message
- - to all recipients
- - do not include original message
- - include original message
- - save to folder
- - move to folder
- - copy to folder
- - set auto-expiration date
- Message Attachment (file)
- - open
- - save as
- - add to Message
- - delete from Message
- Message Template
- - instantiate, use to create message
- - copy
- - select as default
- Private Message Template
- - create
- - modify/edit
- - name, rename
- - delete
- Custom Headers
- - add to Template
- - edit in Template
- - delete from Template
- Public Message Template
- Message Template List
- - display, browse
- - search
- - edit
- - select Template from
- Message Signature
- - create
- - copy
- - edit
- - delete
- - use in message
- Message Folder
- - open
- - close
- - search
- - sort
- - copy
- Private Message Folder
- - set attributes, set options
- - set content auto-expiration date
- - set display options
- User-defined Message Folder
- - create (at top level or in another folder)
- - name, rename
- - delete
- - move
- Built-in Message Folder (does not inherit delete, name, rename, create)
- Inbox
- - retrieve new mail
- Deleted, Wastebasket
- - empty
- Sent
- Drafts (messages in preparation, not ready for sending)
-
- Outbox/Pending/ToBeSent
- Shared Message Folder (everyone with access may manage)
- Public Message Folder (created by admin; anyone can read, only owner can change)
- Folder List, Folder Hierarchy
- - display, browse
- - sort
- - set attributes, set options
- - set display format
- EmailAddress
- - use as Message recipient
- - find (in list or directory)
- User Login Name, User ID
- Organization
- Role
- Room
- Location
- User Public Alias
- Public Distribution List
- User Private Alias
- - create
- - edit address
- - name, rename
- - delete
- Private Distribution List
- - create
- - edit list content
- - add addresses
- - delete addresses
- - revise addresses
- - name, rename
- - delete
- Email Directory
- - display, browse
- - search
- Public, Enterprise-Wide, Directory
- Directory Item
- - create
- - mailto
- Private, Personal Address Book
- - create
- - delete
- - copy
- - add address
- - delete address
- Address Book Item
- - create
- - delete
- - edit
- - mailto
|
The document ends with an enumeration of unresolved (open) conceptual design issues. [Back to Top]
|
- Issue: Is Retrieve Messages an action on the application as a whole or just on the InBox and MyPage folderviews?
- A distinction between Private Alias and Private Distribution List is not really needed, because Private Alias can provide the functionality of both. That is, the only difference between Private Aliases and Private Distribution Lists is in the number of email-addresses that the assigned-name translates into: Private Aliases have one address, while Private Distribution Lists may have multiple addresses. Why not reduce the number of concepts by using the approach used in Eudora, in which a user may assign a nickname to one or more email addresses?
- Deferred delivery messages should, in the long run, be integrated with the calendar, rather than being a special email function. It should be possible to schedule an event that sends an email message to any desired address (including lists) at a specified time, e.g., a person who is going on vacation could set up a recurring event that sends a message to a co-worker reminding him to water his office plants.
- Is automatic mail routing and rule-based filing of messages associated with the Messaging application as a whole or only with the InBasket?
- Is a MeetingInvitation concept needed in Messaging, given that Calendar already includes meeting invitations? Might users confuse the two?
- Is the Address Book related to the Buddy List on My Page? If so, how?
