Chandler Interaction Model

Introduction

For the Chandler rearchitecture project, Jeffrey and I were thinking it would be good to list the interactions the current (1.0) application has with users, so that we can get an idea of what it is we need to create the entire interaction model for Chandler.

Some preliminary notes:

Terminology

For some of the terminology, see the following post by PJE:

http://www.eby-sarna.com/pipermail/peak/2007-November/002799.html

I’m using the following, in particular:

• Feature: A conceptual "piece of user interface"; once instantiated by the presentation layer, may result in more than one widget. For example, a Choice may be represented as a single drop-down, or radio buttons, or menu items with a checkbox.

• Scope: Something that organizes individual features (or sub-scopes, possibly).

At least in my characterization, features are like views, and scopes like controllers, in MVC. Except, of course, there are no views here, and some of the grunt-work that is typical of MVC code is taken care of by the Trellis.

Domain vs Interaction layers:

At the interaction layer, we are largely concerned with properties of Features: Are particular pieces of the user interface visible, or enabled? Are they hooked up to the correct properties of objects in the underlying domain model?

So, for example, something like an item popping to the NOW section in the triage list at its reminder time would actually be modelled in the domain model. There will be some domain-model test that the required attribute would change at the firing time, and there would be tests that the Table feature object reacts appropriately to attribute changes.

Sharing:

Other than the occasional mention, I’m going to steer clear of sharing, as it is primarily a domain-level feature.

Feature Types

Some of these should be self-evident, but for the sake of clarity, I'll enumerate them here:

• Feature: Generic Features are assumed to support various attributes (imported as trellis.Cell objects, of course):
  • enabled
  • visible
  • editable

• Text: Duh, an area displays/can accept text.
• Action: Typically, would be implemented by a button, or possibly a menu item.
• Table: This encompasses both simple lists and full-blown, sortable tables.
• Choice: A list of choices, usually represented by a drop-down or radio buttons.
• Toggle: A simple boolean Choice.
• Date, Time, Interval: Represented by text fields in Chandler, but you can easily imagine custom picker widgets here.
• Address: Used to enter a list of one or more email addresses (or maybe eventually Contacts?)
• Minicalendar: The non-UI parts of our current mini-calendar (e.g. dateRange, selectedDateRange, selectionMode).

Enumeration of Features

• Toolbar:
  • Choice: All/Starred/Calendar
  • Action: Sync
  • Text: Quick Entry
  • Action: Clean Up
  • Action: Send
• Left (sidebar) pane
  • Table: Sidebar
  • Table: Summary View
  • Mini-calendar
• Middle (summary) pane
  • (Calendar View)
    • Calendar Control: Month/Year + Arrows
    • Choice: Time Zone
    • Choice: Day/Week
    • All-Day/AnyTime Calendar
    • Timed Calendar
  • Table: (List View)
    • Model headings as Choice?
    • Sections?
  • Text: (Empty List: currently, custom html for "no items")
• Right (detail) pane
  • Choice: Now/Later/Done
  • Toggle: Starred
  • Toggle: Message
  • Toggle: Event
  • Action: View in New Window
  • Text: Error/Conflict
  • Address: From
  • Address: To
  • Address: CC
  • Address: BCC
  • Text: Byline
  • Choice: Send As
  • Text: Title
  • Text: Location
  • Toggle: All-Day
  • Date: Start
  • Time: Start
  • Date: End
  • Date: End
  • Choice: Time Zone
  • Choice: Status
  • Choice: Occurs
  • TBD: Custom Recurrence
  • Date: Occurrence Ends
  • Choice: Alarm Type
  • Date: Alarm Date
  • Time: Alarm Time
  • Interval: Alarm Interval (before/after)

Scopes

• Application:
  • Has list of top-level Scopes (the frames in wx parlance).
  • Also has cells for various global constructs, like the active shares, or the Sidebar collection, for example.

• Frame:
  • Has a focus attribute to track which Feature (if any) has focus.

• Sidebar:
  • Binds Sidebar table selection and All/Starred/Calendar choice (a filter) to an output collection.

• Summary:
  • Binds Sidebar output collection and All/Starred/Calendar choice to a Feature (Calendar vs List vs Empty List).
  • Has a selection cell which is shared with Calendar and List "features".

• Quick entry:
  • Handles input of text in quick entry field, and ensuring that domain-level code creates items in the correct collections, etc, and possibly ensures that newly entered items are visible (i.e. by changing filter?)

• Dashboard: Sets up:
  • Columns for Dashboard Table
  • Sections for sorting by triage

• Calendar:
  • Assembles the Calendar Control, TimeZone^?, All-Day and Timed Features above. Hooks them up to the correct calendar.

• Detail:
  • Would probably have a set of sub-scopes, because many of the fields are triggered by stamp types, for example.
  • Also needs some notion of "Editing Scope", that has a save API that can be trapped/overridden to handle recurring events. (We can model the recurring event change dialog as Features and Scope objects, too!)

Handling of specific user actions

TBD: Include list of user inputs (e.g. “Double-click in calendar”), and discuss how what components are involved in handling each input, and what cells get updated as a result (e.g. usually, when you create a new item, you select it).

TBD

How do we model drag-and-drop? And copy-and-paste? Might need to have some notion of the pasteboard here.

Need to include menu items (as Actions or Choices).

Could possibly have a Branch scope, that switches between different sub-scopes. This could handle having different views in the summary area.

Current Chandler has a notion of "active view", that is used during event dispatch. The previous section needs to consider whether or not we still need this; for example, it could be handled directly by the aforementioned “branch scope”.

Sometimes, editing a cell in a Table gives you a special, focused editor widget. We probably need to include this in the Table interaction component, as individual cells may or may not be editable via double-clicking.

Read-only (state in detail view, and general affect on interaction with different cells)

Context menus in dashboard view and calendar (for items and empty calendar space)

-- GrantBaillie - 22 Sep 2008