Item Collections Proposal
Background Summary
This summary is a brief restatement of the key concepts that model how users manage sets of items in Chandler. For more information, see Mimi's write-up on
ItemCollectionDesign and Mitch's
notes on the content model.
An
ItemCollection is a set of the user's
ContentItems. Chandler has three different types of
ItemCollection, each with a different behavior and different role in the user interface:
NamedCollection,
AdhocCollection, and
EphemeralCollection.
Named Collections
NamedCollections are the primary, formal collections of
ContentItems in the user's repository. Calendars, projects, and mailboxes are all examples of specific kinds of
NamedCollections, but the user can also create more generic
NamedCollections. These collections persist in the repository, and they have names that identify them to the user. The user usually interacts with these collections in a summary view in the
ContentArea of Chandler (see
SummaryTableViewSpec).
Some
NamedCollections are predefined (also known as out-of-the-box or OOTB): inbox, sent mail, my calendar. The user can also create their own NamedCollections.
A
NamedCollection might be created with a
Rule, or it might be created by the user explicitly dragging
ContentItems into the collection. If the
NamedCollection is created with a Rule, the user can refine the collection by identifying items that should be in the collection but don't meet the rule, and can also identify items that should not be in the collection but do meet the rule. These items can be tracked as additions and exceptions to the rule, instead of changing the items to comply with the rule.
There are some situations when a
ContentItem should be changed as a result of being added to the collection (apart from adding a bidirectional reference to the collection). This behavior is called the
LabelingEffect. This proposal doesn't address the LabelingEffect, we can treat that functionality orthogonally to the general design of ItemCollections, other than to note that a given NamedCollection will have a policy that governs when and how to implement the LabelingEffect.
ContentItems know all of the
NamedCollections they are in. You can see all of these collections in the "See Also" section of the detail view (see
DetailViewSpec).
Ad-Hoc Collections
AdhocCollections are meant to be a lighterweight form of user item collections, and have some different affordances.
An
AdhocCollection is composed of an explicit set of
ContentItems (as opposed to being determined by the results of a Documentation.Rule). Examples of
AdhocCollections: email threads, "to reply to" emails, item history. The user may create an
AdhocCollection explictly via drag and drop actions, or Chandler may automatically create and name the collection via
ProgramAction?: e.g. email threads.
The
summary table view has an affordance where you can select an item and then see a related
AdhocCollection in place in the table.
AdhocCollections can also be the main
ItemCollection in a summary view, just like
NamedCollections.
AdhocCollections also show up in the "See Also" section of the detail view.
Ephemeral Collections
EphemeralCollections are another type of
ItemCollection. These collections represent temporary sets of items, such as the display of the results of a search. EphemeralCollections do not persist, and they do not show up in the "See Also" section of the detail view. If a user wants to persist an
EphemeralCollection, the user can "save" the collection as a
NamedCollection.
Users cannot share an EphemeralCollection, unless they save it as a NamedCollection.
Reference collections
The repository has a general notion of a collection of references to items, called a
ReferenceCollection (or ref collection). ReferenceCollections and ItemCollections are not the same thing, although the implementation of ItemCollections will certainly make use of ReferenceCollections. Whenever an item has an attribute with multiple values that are references to items, the attribute has a RefCollection. ItemCollections, on the other hand, are Items themselves. ItemCollections are a higher level construct, a set of ContentItems managed by the user.
Queries and Rules
A
Query is a repository construct, used to search the repository. A
Rule is an end user construct, the user definition of a search in the repository. Queries will certainly be used to implement Rules. It may be the case that Rules and Queries are the same thing, but we wanted to use separate terms so that the design team can define Rules somewhat independently of the repository's notion of a Query. The ability to support Rules is one of the requirements for Queries. As discussed above, Rules can be used to define
NamedCollections.
CPIA and collections
Blocks and
Views describe the layout of the components of Chandler's user interface. Block and View definitions are Kinds that define widgets that can be used:
SummaryTableView,
CalendarViews, and the
Sidebar are all examples of Block definitions. Block and View instances are the items that are instances of these Kinds: the user's layout data. The instances persist the state of the user's layout: the scrollbar position, the order of the columns, what Views show up in the Sidebar, etc. Views are a special subKind of Blocks: Views can be listed in the Sidebar, can be shared, and may have other special affordances. Every Block has an attribute called
contentSpec, which defines the data contents that the Block displays. Although we may have more complex views down the road, a typical View will have a contentSpec with an ItemCollection or a ContentItem as a value. The View may be transparent to the user, who will likely be focused on the ItemCollection or the ContentItem, the data that the View is presenting.
Calendars. Projects and Mailboxes
Calendars, Projects and Mailboxes are all special cases of NamedCollections, with special affordances. The user can define the contents of a Calendar, Mailbox or Project in the same way that they define any NamedCollection: by explicitly listing the included ContentItems, or by defining a Rule with exceptions and additions. We will have Calendar, Project and Mailbox Kinds, which are subKinds of NamedCollection. Note that these Kinds define a collection of data, and can potentially be the contentSpec for different kinds of Views: a Calendar
ItemCollection can be seen in a Summary Table View or a Month View. Similarly, other kinds of ItemCollections might be viewed in a Month View, even though they are not "Calendars".
Open Questions, Notes, Issues
- Is the labeling effect policy part of the view? Or part of the item collection?
- In general, what data lives with the view and what data lives with the item collection?
- If you save an ephemeral collection that you got as the result of a search, is the search criteria saved as a Rule, or is the collection saved as an explicit list?
- We'd like to change the name of the attribute "contentSpec" to "contents"
- Notification strategy ought to be added to this spec -- when/how does the collection get notified to changes of its contents.
Notes on API
- contentItem api:
- what are all of the projects this contentItem is found in?
- what are all of the calendars this contentItem is found in?
- what are all of the ad-hoc collections this contentItem is found in?
- what are all of the generic, named collections this contentItem is found in?
- calendar, project, ad-hoc, named collection, item collection apis:
- what are all of the members of this collection?
The NamedCollection subKinds must be able to use the same implementation as NamedCollection. That means that when calendar and project instances ask for all of their members, they must get all of the contentItems that use the project/projectItems bidirectional relationships and the calendar/calendarItems bidirectional relationships.
Collection related terminology
- reference collection - A repository term, an ordered set of item references. If an item has an attribute with multiple values, and the values are references to items, then the attribute will return a reference collection.
|
- Named collection - A named collection is the second of three types of Chandler collections. A named collection is a persistent collection of content items. Named collections are a combination of behaviors taken from rule-based collections, explicit collections and program action collections. A named container can start out as a simple explicit collection populated by explicit user DnD? manipulations. Users can add a rule to named collections where the named collection will act as a container that is in turn populated by the rule. Users can then perform DnD? manipulations to add and remove items from the collection that violate the rule. Named collections may exhibit a labeling effect. All items added to the collection can be optionally labeled by any label attributes values specified by the rule. (ie. All items in a rule-based collection defined by All tasks with a status of Blocked would be labeled Blocked.)
|
- Ad-hoc collection - An ad-hoc collection is the third type of Chandler collection. It is essentially an explicit collection, comprised of a tightly controlled set of ordered items that the user creates through explicit DnD? manipulations. However, there will be some OOTB? auto-generated collections including Email threads and possible notifications. User rules cannot be added to ad-hoc collections unless the user converts an ad-hoc collection into named collections byDnD?ing it into the sidebar. Ad-hoc collections are designed to satisfy user needs for a lightweight way to relate items. They possess a special set of UI affordances to make them especially easy to create and maintain. Ad-hoc collections are currently the only type of collection that 1) can be created by DnD?ing items onto each other 2) auto-named upon creation and 3) open up in-place in the table summary view type. Ad-hoc collections appear in the "See also" section of member items' Detail views.
|
- Ephemeral collection - An ephemeral collection is the first of three types of Chandler collections. It is a user initiated temporary rule result set. Ephemeral collections do not have names. Users think of ephemeral collections not as containers poulated by rules but as the queries themselves. Any explicit DnD? manipulations to add or remove items from ephemeral collections do not persist unless the user saves and names the collection. Ephemeral collections do not appear in the "See also" section of their member items' Detail views.
- See also ItemCollectionDesign?
- See also RuleBuildingWorkflows?
- See also ItemCollection
- See also Rule
- See also SeeAlsoSection?
|
- Rule - A rule is a user-defined query. Rules can be used to populate ItemCollections. (Note: Rules will likely be implemented using Queries, Rule is an implementation neutral term for the end user concept.)
|
--
KatieCappsParlante - 29 Apr 2004
Log In