Chandler Presentation and Interaction Architecture (CPIA) Overview

This page is obsolete. See CpiaZeroPointFourStatus for the latest information.

Disclaimer: CPIA is still very much in the design phase. The only thing that we can say with absolute certainty about CPIA is that it will change when it comes time to implement it. Furthermore, we probably won't get everything that we describe here into the 1.0 release.

---

This document describes the Chandler Presentation and Interaction Architecture (CPIA) -- the way that Chandler displays information on the screen and accepts input from the user.

Blocks

The fundamental building block of CPIA is the block. Blocks are nestable descriptions of layout coupled with data elements. Instead of needing to write code to populate the layout elements, users can edit a simple string -- the content-spec -- that describes the data. This is very similar in many ways to spreadsheet cells, where users determine which data appears in cells by editing strings associated with the cells (e.g. A$5 or MAX(A7:B43)).

Note that blocks are not functional elements themselves, but contain descriptions of what the layout should look like. That layout could then be implemented by a variety of different presentation frameworks. For example, a given tree of blocks could be rendered by wxWindow widgets or by HTML elements.

A CPIA blocks' content-spec can be the results of a query of the user's Chandler Repository. For example, a block could have a content-spec query for any item with a "Cobra project" attribute. The block could then display email messages, contacts, tasks, and calendar events mixed together, instead of just email messages, just tasks, or just calendar events.

In addition to straight queries, a block's content can depend upon another element's content. For example, a block's content-spec could be "all messages from the person selected in block 'MostRecentMessage'" or "all tasks listed in my parent's block". This is similar to how cells in a spreadsheet can be functions of other cells, e.g. $M$36*2.

Chandler will contain a graphical application "editor" which will make it possible to alter the appearance and/or behavior of blocks in the same way a word processor makes it possible to create and edit a document. Users will be able to resize, move, and delete blocks or to add elements by dragging and dropping from a palette of elements. Blocks will include not only familiar components like buttons, but also much more sophisticated and complex objects, like an email Inbox.

Documents

Documents are trees of blocks that represent a top-level view of data from a user's perspective. In some sense, Documents are "complete" in a way that other collections of blocks are not. For example, an email inbox Document could carry with it a reply button, a "view next message button", and all the other controls needed to interact meaningfully with an email inbox. A reply button in isolation, by contrast, is incomplete -- it needs a selected message to be meaningful. Documents have everything they need; they are not just a part of some larger element.

Documents are addressable by a URL and can be shared (with meaningful access controls) with other people.

In the image below, the shaded area is a document:

In the example shown at left, the Document contains several blocks: one that holds all the messages in the inbox one that contains the "unit 47" message. several buttons for various actions (e.g. "Reply", "Forward", and "Delete")

The top block of a Document (the root block) contains some additional "application-esque" information that other blocks don't have. For example, root blocks specify event-handling code. They also connect to the code for handling domain-specific chores. For example, the email Document's root block will hold the connections to the code for downloading messages.

Chandler will allow users to easily share Documents with other users in either absolute or relative forms. For example, Joan can add a button to her Inbox, then share her Inbox with Jack. She can either share so that

• Jack sees his own inbox, with messages that were sent to him, with Joan's new button or
• Jack sees Joan's inbox, with messages that were sent to Joan, with Joan's new button

This is similar to how spreadsheet cells can be either absolute ($B$67) or relative (B67).

Contexts

Contexts are at a level between Documents and the overall Chandler application. Contexts contain a collection of documents (possibly only one) For example, you might have an Email Context that contains Inbox Document, a Sent Messages Document, a Messages from Lee Document, and so forth.

In most contexts, one of the documents in a Context will have the focus and be large; all the other documents in a Context will be scaled down to a very small size.

Contexts will usually display some agents and control elements that are useful to all Documents of a certain type.

Chandler will probably have an Email Context, a Calendar Context, a Contacts Context, an Instant Messaging Context, etc. In the image below, the Email Context area is shaded:

The Context has miniature images of the various documents in the Context. This picture doesn't show any controls or agents that are specific to the Email Context, but they would show up in the shaded area.

The astute reader will notice that there are buttons in the context area (Reply, Forward, etc) that are not shaded. Those buttons belong to the Document but are projected into the Context area. The Document can also project buttons into the Toolbar.

(Note: Contexts are analogous to "Viewer parcels" in the existing Chandler framework.)

Using CPIA: Examples

Chandler will allow end-users to resize, move, and delete blocks, to add blocks from a palette of available blocks, and to define what content should be encapsulated in those blocks. For example, a user could easily create:

• a line of text that displays, "You have X unread messages from your boss", where X is calculated from a query on the inbox
• a list of messages from her boss
• a custom document with information about his wife's surprise birthday party, with:
  • a Time View block with a content query that shows only events tagged with "Elaine Surprise Party"
  • a block containing the body of the email message announcing the party
  • a table block which contains a list of the invitees and the tasks each attendee has volunteered for
  • a block with email messages related to the party

Here is an example of what such a custom "surprise party" document could look like:

Note that because blocks are Items persisted in the Chandler Repository, any customization that the user makes to their UI can easily be shared with other users. Also, when the nomadic access feature is developed (in the Westwood timeframe), any customization a user does will be reflected across any computer where the user logs in.

Implementation Details

Properties of blocks

We expect that blocks will have long lists of properties. We expect that most will have the following:

• Block-name is used to reference the block in a fashion that programmers and users can understand. The block-name will usually be used when humans create relative block references. Note that unless otherwise specified (in a manner to be determined), block names refer only to other blocks in the same Document tree. In other words, a block named "Foo" in an Inbox Document's root block will not conflict with a block named "foo" in a Contacts Document.
• Block-type defines the type of the block, analagous to the class of the block. (See below for a list of block-types.)
• Content-spec defines what content the block displays. Most content-specs resolve to an item or set of items. The content-spec can be
  • a query, such as, "all email messages from Andai"
  • a reference to another block, such as "the sender of the message in my parent's block"
  • a query that references another block, such as "all messages from the person in block LastSentMessage"
• Children: some blocks can contain other blocks.
• Format: Every type of block will have a set of format properties. CPIA will support named styles which have a set of style-properties (e.g. "Font") and style-property-values (e.g. "Helvetica"). We expect that there will be a hierarchy of styles, with styles associated blocks deeper in the block hierarchy overriding those associated with blocks higher in the tree.
  • a list of Items (or more specifically, a list of the Item's unique IDs)
• Open/Closed Boolean defines whether a block's children are displayed or not. Open and closed are allowed to have different styles. When a block is closed, there is an option of showing a summary of the block. For example, in an outline block, an intermediate node might show all its children when "open" and the number of child nodes when "closed". For a leaf email node, it might display the entire message when "open" and only the subject line when "closed".
• Notifications: Blocks use the Notification Manager to handle notifications (called "events" in many other frameworks), but the block will keep a list of notifications that it might produce and those that it might consume. There are two kinds of notifications associated with blocks: simple notifications (like button presses) and more complex notifications associated with higher-level Chandler actions. For example, an Email Document's root block respond to the notification that a new email message arrived. For the higher-level notifications, the associated Document's root block will come "pre-wired" to handle the notification appropriately.
• Sharing, permissions, other behavior: Because all blocks are first-class Chandler Items, they all will have (or inherit) access control policies. (For many blocks, it will not be particularly useful to share them individually, but only at a page level.)

Block types

There are several types of blocks, in a hierarchy that has yet to be determined. Some blocks are used mostly to display summaries of lots of different pieces of data:

• Container blocks exist only to organize blocks spatially inside themselves. A container may include a window style, size and location which can be used to implement floating windows (e.g. palettes), modal and modeless windows and dialogs, and main windows. They may have optional realization-specific representations, e.g. XRC2. Types of container block are:
  • Relative positioning: These container blocks automatically calculate the position of the sub-blocks arranged horizontally, vertically, or in a two dimensional grid. The layout of child elements will probably be expressed in terms of their minimum size, what resizing is possible, and how each child relates to each other and their bounding rectangle (e.g. "at the upper left-hand corner of the bounding box and full height" or "at the lower right of the previous child").
    • Box Container: Horizontal or Vertical one dimensional list of blocks.
    • Grid Box Container: Two dimensional array of blocks
  • XY (or Form) Container: These blocks define the positioning of their children in absolute display coordinates.
  • Tabbed Containters: allow switching quickly between different display blocks using a tabbed control, as in a tabbed dialog. For example, you could imagine a Calendar Context with week-view, month-view, and day-view on different tabs, with only one visible at a time.
  • Group Box Container: A container with a rectangular line drawn around the contained blocks, usually used to visually group controls in into related sections. Includes a text title description.
  • Bar container: A container used to implement toolbars and statusbars. Bar containers allow the user to select icons and/or text, and the cell padding is editable.
  • Embedding Containers: allow referencing (and including) Documents by means other than direct references or platform-specific display types (like Active X viewers). Blocks that do not have direct references are tricker to deal with than those with direct references: the access is slower and before using an indirectly-referenced block, you must verify that the block still exists.

• Control Blocks
  • Button Blocks might be a variety of styles including plain and checkbox. To group one or more button so they work like radio buttons, place them in a container and set the radio button container style.
    • Link blocks will probably be implemented as buttons but resemble Web hyperlinks. Note that Chandler will probably use hyperlinks mostly to take users to other places inside Chandler and not to the Web.
  • Image/Icon blocks
  • Edit Text blocks handle both single line and multi-line text, as well as rich text or HTML text. Styles include read-only and Chandler recognition.
    • Static text blocks are like lightweight Edit Text blocks but don't have a box around them and are read-only.
  • Analog display blocks are used for input and/or output of a numeric range. Examples include scrollbars, dials and progress bars.
  • List box blocks: A vertical list in a scroll box. This may be handled by a Table (see below), or it might have a combobox style.
  • Popup List blocks: A button that displays a list of choices (or menu) when clicked on.
  • Menu and menu item blocks: May have a context menu style
  • Agent blocks display the anthropomorphic representation of an Agents' state. They have a defined rectangle, but the agent code itself is responsible for what's displayed in that rectangle.
  • Tree blocks represent the platform specific tree widget. (This might be eliminated by the Outline block.)
  • Simple table blocks are are two-dimensional displays of data. Note that simple table blocks are not containers. All the data lives inside the simple table block, with none in child blocks (unlike e.g. a Grid Container block). Table blocks allow resorting based on the column headers. Note that lists can be implemented as simple tables with only one column. For simple table blocks (and any other type of block that contains multiple elements), there will be a way (which we haven't specified yet) to address elements individually, e.g. a row-column indexing. Table blocks also can be sectioned, so that tables have subheadings.
  • Outline blocks display trees of data, where each sub-element can be expanded and collapsed. We expect that we will need two outline blocks: one that has a tree of nested blocks, and one where all the sub-elements are contained directly in the outline block (in a manner similar to the simple table blocks).
  • Time View blocks display time-ordered sets of Items (e.g. Calendar events or a timeline of email message arrivals):
    • Day View blocks
    • Week View blocks
    • Month View blocks
  • Item Block: Views/Edits a single Chandler item.

• Picker Blocks: Each of the picker blocks is a platform specify dialog and consists of:
  • DateTime Picker block
  • Color Picker block
  • Open/Save file/item Picker block
  • Font Picker block
  • Print Picker block
  • Page Setup Picker block
  • Print preview Picker block
  • Find Picker block

• Controller blocks handle messages and implement the controller functionality in the Model- View-Controller architecture. The main Chandler window typically consists of three nested documents: the application context, which contains the document context, which in turn contains documents. Controllers hang off each of these three documents and implement application behavior by handling and processing high level Chandler events.

Note that, in general, a block can only live in one place at a time. Embedding blocks offer one way to bypass that restriction, and open up a host of data consistency and coherency issues. We believe that those issues will be difficult, that they are solvable, and that we will need to solve them.

Documents have a root block which multiply inherits from a container block and a Document Item. Although the first even though the root block is a subclass of Document, when we refer to "docuemnt", we refer to the entire tree.

Phrase Construction

An important design goal is to be able to mix and match data types in displayed collections. To facilitate presenting mixed data types, Chandler container blocks have attributes "phrases", which display a string created from text and a number of different attributes in a formulaic way. These phrases can then be used to compactly display mixed data types:

Type	Headline	Done
Email	From Chantelle re: unit 47 down at 8:07 AM today
Email	From Pat re: unit 47 down at 8:09 AM today
Task	Urgent! Fix unit 47
Task	Low-priority: Fix unit 47
Calendar	maintenance passdown meeting at 2:00 PM today
Contact	Andy Nguyen from Hoopston Equipment, 917/555-2538

This is display is much more compact than if a traditional, one-field-per-column method were used.

Phrases might be useful in other circumstances. For example, phrase blocks might be useful as templates for email responses, in a way similar to how "mail merge" is done.

We are not completely sure how phrase blocks will be implemented or exactly how the user will interact with them. Possible ways to construct them include:

• via a graphical, drag-and drop contstruction mode
• via a text substitution language (e.g. "From $$MAIL.SENDER re: $$MAIL.SUBJECT at $$MAIL.DATE")
• automatic creation via recognizers

We do know that we want to allow "item-hopping" -- being able to refer to a field that isn't in the immediate record. For example, we'd like to allow displaying the sender's phone number in a phrase block associated with an email message, even though the phone number is not part of the email message. For example, if a phrase substitution language is used, we want to allow something like "$$MAIL.SENDER.PHONENUMBER".

Open issues

-- DuckySherwood - 20 Aug 2003

---

---

-- DuckySherwood - 11 Sep 2003