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

Conceptual Model

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.

General User Interface Approach

This section provides an overview of the design constraints, major functional facilities, and conceptual design decisions. [Back to Top]


The general user-interface approach for Jupiter Messaging application is subject to the following constraints:

Major Facilities

The Jupiter Messaging application will consist of the following facilities:

The following diagram shows how the facilities are related in the sense that they require access to each other.

Diagram showing how the facilities are related.

Conceptual Design Decisions

The conceptual model embodies the following design decisions:

Object-Action Analysis

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:

Following the Object-Action Analysis are Notes and Issues about it.

Objects and Actions for Jupiter Messaging

- 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

- start, invoke
- stop, quit, exit, dismiss

Jupiter Help Facility (Email section)
- browse
- start, invoke
- stop, quit, exit, dismiss

- start, invoke
- stop, quit, exit, dismiss

Spellchecker Dictionery
- add word

- open
- print
- delete
- copy text from

- 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)

- retrieve new mail

Deleted, Wastebasket
- empty


Drafts (messages in preparation, not ready for sending)


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

- use as Message recipient
- find (in list or directory)

User Login Name, User ID





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

Open Conceptual Design Issues

The document ends with an enumeration of unresolved (open) conceptual design issues. [Back to Top]

  1. Issue: Is Retrieve Messages an action on the application as a whole or just on the InBox and MyPage folderviews?
  2. 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?
  3. 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.
  4. Is automatic mail routing and rule-based filing of messages associated with the Messaging application as a whole or only with the InBasket?
  5. Is a MeetingInvitation concept needed in Messaging, given that Calendar already includes meeting invitations? Might users confuse the two?
  6. Is the Address Book related to the Buddy List on My Page? If so, how?