I've recast my previous notes about the content model more into the form of design requirements. I removed the link to ContentModelDashboard from the Content Model project. I think development should figure out what to do over in that part of the wiki. This document should perhaps go into the Design part of the Chandler wiki.

Change Log

4/29/04

• added discussion and definitions of ad hoc collectiion types
• added discussion about collection befined by program actions vs. collections defined by rules
• refined open issues list on collections of both types
• added notes on proposals for built-in collections
• introduced discussion of item history and versions

Notes on Design Requirements for Content Model

From a user-facing perspective, there are two principal types of collections, currently called "named" and "ad hoc", each of which has distinctive affordances. Below is a summary. See also ItemCollectionDesign

Named collections

• may be predefined or user created
• may have an associated rule
• if it has a rule, then there are policies for expliucit add and remove (formerly DnD policy)
• not openable in place in a summary view

Examples of named collections

• projects
• mailboxes - an individual mailbox such as Inbox, Saved, OSAF Dev mailing list
• calendars - Mitch's Calendar, Family
• "spheres of life"
  • Work
  • Personal
• generic (other)

Default named collections

• Mailboxes: In, Out, Trash, Junk (keep an attribute on mail from "me" as to draft, queued, sent, etc.)
• Calendars: 's Calendar, possibly a second default calendar
• Work, Personal

NAMED COLLECTION ISSUES

• for each default named collection, what are its explicit add and remove policies?
• for each default named collection, can it be (a) deleted, (b) renamed?
• for each type of named collection, can new ones be added?
• if there is a second default calendar, what is its name?

Ad Hoc Collections

• intended to be use as smaller, more lightweight collections
• will have different UI affordances
• automatically created and named by Chandler
• may be renamed by user
• are permissive about explicit additions, i.e., can drop a task on a thread
• see AdHocCollectionsWorkflows^?

Examples of Ad Hoc Collections

• threads
• @context items, by context, e.g. @home, @work, @phone (Note: this is new!)
• "to reply to" emails
• item history
• send/sharing history

AD HOC COLLECTIONS ISSUES

• define requirements for item history, send/sharing history
• are collections ordered? it would seem that they might need to be in order to capture the threading history
• what is the fine-grained structure of capturing not only email threads (reply chains) but also forwardings.

Thoughts on item history, versions

For the user, not every low-level change to an item should constitute a distinct version of the item. So, if I am editing an item and make several changes, the intent is better captured by the idea that all of the changes together constitute a version. For instance, successive synchronizations of a changing item should be stored as versions in the item history, i.e., as separate items in an ad hoc collection.

There could be an affordance for a manual "save a version..." command, but the art will be in transparent, meaningful saving of versions. Besides events, what other types of items would one naturally want to save versions of?

A Subtle Issue

There are two ways to model collections which have similar but not identical affordances. With a mailbox collection like In or Out, for instance, there is no explicit rule which governs it. The principal way Items are placed in the collection is by virtue of what I will call program actions, i.e., when a new mail message is received, it's added to the In collection (unless it's filtered out, but let's keep the story simple for now). On the other hand, I could define a calendar collection called Tentative Events, with a rule that says to include an item if it is an event and has an event stgatus which is tentative. In this case there is an explicit rule, which is editable by the user, so that if we designed the program to provide such a collection by default, the user could change it, whereas they cannot change the collection behvior if it is defined by program action. So there is a choice to be made when we model the built=-in collections which we way do it, i.e., whether we expose a separate attribute. In general, I am leaning to the idea that built-in collection be defined by program action, not by a distinct attribute + collection rule.

Collections and Rules

• When a named collection has a rule, there must also be a policy for handling explicit additions and removals, e.g., via drag and drop
• Prohibit - dragging and dropping is not permitted
• Allow by maintaining explicit lists of what has added and removed
• Allow by conversion
  • is possible if, for instance, rule is defined in terms of a single, "non-intrinsic" attribute, e.g., sphere of life = work
  • this won't always be possible for every rule, so if this is the option, what happens then?
  • Mimi refers to this as the "label effect"
• Allow and take some specific action
  • Not called for in current UI spec, but could be very useful, general mechanism

see also Mimi's rough sketch for a rule-building UI, URL tk

RULES AND COLLECTIONS ISSUES:

• need to define requirements for

  DnD policy

  actions, also a better name for

  DnD policy

• need to define which attributes are "intrinsic" - MK, Mimi

Ad Hoc collections

• have a generated name, may be renamed by user
• may not have a rule
• openable "in place" in a summary view
• typical uses: email thread

Content Item

• creator
• creation date
• last modification date
• subject
  • a general subject, such as might be found in a library card catalog
  • values should be a enumerated hierarchy

• conversations
• contained notes

• @contexts (represents necessary condition for performance, e.g., @office means "can only be done when I am at the office"
  • @office
  • @home
  • @ phone

• importance
  • important
  • fyi

Content Items and Date Patterns

• must support all of these (we want to treat events, emails, tasks, notes equally as regards date patterns)

• no date at all
• just a date: May 23, 2004 (all-day event, ChaoLam: also "anytime this day" events?)
• multi-day event
• a date and a time: 7:50 AM PDT, May 23, 2004
• a date and a time, and an end date and time: 7:50 AM PDT, May 23, 2004 to 9:00 AM PDT, May 23, 2004
  • duration is serived from start and end time

• recurrence - for any content item except one with no date, support a recurrence pattern
• tickler (attribute of content item) - a specific date and time associated with a content item, not appearing on calendar per se, but meant as a trigger for some kind of action.
  • tickler (as item) - in addition to the content item to which it's linked, its date and time, we also need to define some class of actions to be taken such as "play a sound", "stick in the processing section of dashboard view, etc." Needs further work.

ISSUES:

• is it ever the case you want the tickler on your calendar?
• need to define requirements for ticker actions

Participant

• Every content item can have one or more participants, which is a contact.
• In the context of a sub-kind of content item, a participant can have a role (example: organizer, attendee, requestor)
• With every kind of content item, there can be particular roles.
  • Example: every event can have an organizer
  • Example: every task can have a requestor
• If there is an event "foo" whose organizer is Fred, and a task "bar" whose requestor is also Fred, then content items where Fred is a participant would include both "foo" and "bar" items

ISSUE

• Different kinds of participants and attributes thereof must be worked out

Event

• headline
• event status - tentative, confirmed, cancelled
• location
• resources
• related mail message
• time transparency

ISSUES

• details of event attributes, especially compatibility issues
• event participants and roles
• requirements for location, resources. Could tasks have these?

Task

• description
• task status
• related mail message

ISSUES

• task participants and roles
• task due date - is this an event associated with the task? I think so. That way it can have reminders, recurrences, etc. Or it could be an associated task milestone, with a milestone type (like start, due, etc.) similar to participants. But suggest we not do this now.
• task "doneness"
• we ought to rationalize event headline, task description, etc., etc.

Note

• if we figure out how to rationalize headline/body, then I don't think there is anything in a note that makes it at all different than a (generic) content item)

MORE ISSUES

• requirements for, Instant Message, Email, Document, Attachment
• requirements for content item sharing
• item histories
• requirements for notification and logging
• ad hoc attributes (i.e.. categories), user defined collection types?
• interoperability-related issues
• which layer things fit in (Chandler, Core Content Model, PIM Parcel)
• requirements for Contact, include "me", group and relationship to underlying kinds like Principal, Permission, �ertificate
• rationalization of content model with "mix view" requirements - "who", "when", "what"

contacts mentioned in items and collections (feature idea)

• for a given collection, determine all of the contacts "mentioned" in its items (as participants? in textual content of messages?
  • this would be sort of dynamic contact group. are we already planning to have these or not?
• for a given contact, show all of the collections in which it is mentioned

-- MitchKapor - 27 Apr 2004

Hello Mitch. I was reading this page and one item jumped out at me that I wanted to comment on regarding the handling of time. Specifically regarding your Content Items and Date Patterns above, an international and rigorously defined standard already exists for expressing the semantics of a point in time to various degrees of exactness, time zones and ranges of time that you mentioned, ISO 8601. That's the best summary reference I found on the topic when I recently did some google searches. Two more detailed references I found useful were from New Zealand and Finland. The World Wide Web Consortium also recommends the use ofa form of ISO 8601.

-- GrantBowman - 09 Jun 2004