Rule builder as Assembly Line

Status We've decided that this is out of scope for Canoga. The Dashboard view will be our OOTB, pre-fab assembly line, designed to satisfy most of the "processing" and lifecycle use cases for personal information management. Allowing users to create from scratch their own assembly lines for general information management will be a post-Canoga priority. Most of the use cases we were able to come up with seem to be most useful for enterprise, large-scale organizations that have fixed and predefined processes and procedures. To do this right, we would need to do wider and deeper use cases analyses.

Vision Create a rule builder that will allow users to create an assembly line of collections that actively mark, label, process and operate on items

Use cases

• Process HR paperwork
• Process college applications
• Complex task management (ie. Bugzilla)
• Automate lunch orders

Sample assembly lines: Automate lunch orders

• Take-in collection:
• Add all messages about [Lunch]
• Mark all messages from Geri, Carol, Mustafa as Vegan
• Mark all messages from Jeanette, Davidos as Vegetarian
• Mark all messages from Samuel as Allergic to Wheat
• Move messages to Order collection

• Order collection
• Forward all messages to orders@waiter.com

• Confirmation collection
• Add all confirmation messages from waiter.com
• Forward confirmation messages to original senders

Structure

The rule builder is essentially the same as the browser with one important exception: the notion of an action. In addition to the attribute and attribute value, each column of the rule builder also specifices:

1. Put in here
2. Take out of here
3. Mark / Label as

• rule_builder_column.gif:
  

Users can further tweak actions by

• Turning on / off "labeling effect"
• Allowing for DnD inclusions / exclusions to violate the rule

Advanced rule builder functionality: Creating a rule matrix

• Columns that are side by side have an AND relationship
• Columns that are above and below have an OR relationship.
• rule_builder_matrix.gif:
  

The rule builder is reflected in the Search bar (see Browser^?).

The rule builder combined with the Browser filter can be read continuously from left to right as a description of what content items you see in the summary view. Users should be able to DnD columns from the browser into the base rule to add parameters to the base rule.

• add_to_rule.gif:
  

Structure: Justification for the Assembly line metaphor

Q Why do we want to include this notion of ACTIONS in the rule builder?
A Assembly line metaphor: Modeling a content item's life cycle with collections
We talked briefly about content items having a life cycle in both ItemCollectionDesign and the DashboardViewSpec. Items have a life cycle in the sense that they go through various stages, phases, processes from when they first enter the PIM to when they find their final resting place either in a reference file somewhere or in the trash can. We want to make it generally easy for users to create life cycle assembly lines for their items, but OOTB, Chandler should offer templates for the most important kinds of life cycles.

The mechanics of life cycle assembly lines
Life cycle processing is modeled using mutually exclusive attributes (ie. the life cycle of a Task might be a series of rule-based collections governed by Task status: PENDING / BLOCKED --> UNBLOCKED TODO --> DONE) [insert storyboard].

• task_lifecycle.gif:
  

OOTB, Chandler provides a generic solution to processing items with the Dashboard view. The Dashboard view is essentially Command Central of all content item life cycle assembly lines. It is where users perform high level coarse-grain triage, marking some items to be filed as reference, keeping other items around to be dealt with immediately and tickling items to get dumped back into the Dashboard view at a later date.

• Triage_Workflow.gif:
  

It would be nice to extend this life cycle framework to all collections so that users can create more fine-grain life cycle processing assembly lines. Collections will not be dead-end containers for items. Instead they will link up together, participate in an assembly line of stages, phases, processes, a veritable chain reaction passing items to and fro, marking, labeling, moving, filing generating a veritable cacophonous symphony of activity, some automated others user-invocated. In reality, it probably won't be that exciting. But we can probably solve some very common use cases (ie. mailing lists) that make a lot of sense as life cycle processes.

Workflow proposal for creating mailing list filters

• User clicks on "New collection" button in sidebar
• User selects "Mailbox" for type of collection
• User names new mailbox: OSAF Design List
• User drags and drops an OSAF Design List email into the collection
• Dialog: Do you want to automatically move all email To: design@osafoundation.org to this collection?
• User clicks yes.
• Chandler automagically sets the OSAF Design List collection's base rule to
  • PUT IN HERE all items To: design@osafoundation.org AND
  • MARK as Stored (this takes it out of the Processing Bin and puts it into the Stored section of the Dashboard view)
• Optional
• User can tweak the base rule by opening up the Rule Builder inside of the collection
• mail_filter_workflow.gif:
  

-- MimiYin - 24 Jul 2004