Purpose of our series of design meetings and accompanying documentation is to arrive at general consensus and to be able to communicate a set of core design decisions and feature specifications for Canoga so that developers feel they have sufficient context and specificity to implement Canoga in the most productive and empowering manner.

Goals or deliverables (deliverables will be produced in an incremental, iterative fashion, see approach below)

1. A set of visual and interactive design specifications of the primary "built-in" or default Capplets (in the form of CPIA documents) that will ship with Canoga.
2. A set of features with sufficient (but not over-) specificity for each primary Capplet and Canoga as a whole
3. A remaining set of ongoing list of OpenDesignIssues that we will be tackling. This list needs to be prioritized and should shrink dramatically over the next few weeks as we either solve the issue or decide to defer it past Canoga.
4. A GlossaryOfKeyEndUserTerminology we can all agree on and use consistently.

Approach

• The Design Team comprises Mitch, Andy, Mimi, Brian, Ducky and Chao.
  • Mitch, Andy, and Mimi bring their respective strong design experience. They are the keepers of the soul of Chandler and are responsible for actually solving the thorny design issues.
  • Mimi is responsible for goal 1.
  • Brian is responsible the data model and PIM schema of Chandler. He is also the developer liaison in terms of raising implementation issues in the design meeting and keep developers abreast of new architecture and data model requirements. Brian is also helping Chao is overall product management (especially next week when Chao is away).
  • Ducky is responsible for taking detailed notes in our design meetings and assisting Mimi in developing user scenarios.
  • Chao is responsible for ensuring overall progress towards above goals which entails coordinating requirements of all parties, getting alignment, resolving conflicts, synthesizing and communicating progress.
• The FeaturePrioritizationMeeting20030827 and FeaturePrioritizationWorkPlan details how we arrive at a candidate list of features for each major component of Canoga. This list also generates a list of open design issues.
• Through Mimi's goal of designing a visual and interaction framework for Canoga, Mimi generates a list of open design issues that she needs answered.
• Through Brian's goal of designing a PIM schema, Brian generates a list of open design issues
• Chao works closely with Mimi, Brian and rest of design team to create a combined list of open issues and to prioritize them. The prioritized list then becomes a basis for setting the agenda for a series of design meetings with the design team.
• In our design meetings, we usually go through and make decisions on open issues, go through proposals for solving harder open issues (usually by Mitch and Mimi) and decide which issues and features to defer.
• Generally, we use common user scenarios to guide and align our decision-making. We are developing a set of reference usage patterns at DaveAllenUsagePatterns
• As such decisions are made, we need to go through the feature prioritization lists to make sure they still reflect reality and we communicate and discuss such results with the individual developer (if hired) responsible for that area.
• The above process is extremely iterative. All the above are happening in parallel. We need to make sure they are well coordinated and communicated, so that we are continually moving towards our goals.

Decisions and issues discussed to date:

Target audience: Canoga is targeted for info-centric users as defined further in our Product Road Map. A few clarifications:

• Target user is a non-technical power-user. We do not expect users to think like programmers.
• It is most important that Canoga must be a great application first, and a great application platform second. In the application areas, we will focus primarily on Email, Calendar and Tasks (ECT). A very simple version of IM and notes will be provided as well with the primary emphasis for IM and Notes being to support the ECT application areas. Contacts will also be provided with the focus that it is a long-lived resource in seamlessly enabling ECT tasks. We are deferring web bookmark and external document management as content items in Canoga.
• Other capplets will not be implemented by OSAF in Canoga. We expect, hope for and encourage, as an open-source platform, that other capplets will emerge. However, this will not be a focal area for our efforts in Canoga.
• See DesignIssuesMeeting20031106 for more details on our target audience.

#Trash.DesignToDoList Design Map

• The following shows a high-level grouping of all the design issues

• The major capplets are Email, Calendar and Tasks.
• Major capplets treated as silos are reasonably well-understood. We are developing a set of high-level specs for each.
• Of course, Chandler will not treat capplets solely as silos. Generic Info Mgmt deals with Item inter-relationships, grouping and categorizing, especially in a task-oriented context. All of Chandler's PIM information is contained is the same continuous PIM information landscape. Ideally, users should have the right filter or lens to see just the relevant information for the task at hand. LevelsOfUse explains the different types of views we will provide, which provides traditional trade-offs between ease of use/understanding and power-user flexibility and sophistication.
• User, contacts and groups is another major area. It is a bridge between generic info mgmt and sharing. We have made some key design approaches in this area.
• Sharing is a one of our compelling, cool feature areas. This will be our next area of discussion and I'm compiling a list of sharing-related issues.
• The above represents the core high-level end user model of Chandler. After dealing with the above issues, we go down more to the underlying frameworks and more specific design issues. Areas include:
  • CPIA
  • Search
  • Security and Privacy
• For more details, see DesignProgram

Feature Prioritization of Capplets (silo perspective)

• Email: See EmailDesign and SpecificDebatableEmailFeatures.
• Calendar: See CalendarFeatureList2004.
• Tasks: See meeting notes at DesignIssuesMeeting20031110. List of minimum feature list candidates is at TasksFeatureList20031121.
• Notes: See meeting notes at NotesDetailedFeatureList^? and DesignIssuesMeeting20031106. List of minimum feature list candidates is at NotesSummarizedFeatureList^?.
• Contacts: See outdated version at ContactsDesign. To be revised by Chao early Dec.
• [OT]Instant Messaging: Open Topic. No specification yet.

Generic Information Management

• Being task-centric in a PIM means providing the right set of inter-relationships of items for the current task at hand. This capability is at the core of what Chandler is. However, with finite resources, Canoga will only demonstrate these capabilities of Chandler in the most compelling but finite (around a dozen) number of ways. More esoteric inter-relationships will just have to be provided post-canoga (or contributed by the community).
• Here are the main requirements around generic information management:
  • We acknowledge that there are different modes or stages of workflows. We need to provide tools and views that support each of the workflow.
  • Ideally, users want to see (just) the relevant set of information items for each current task at hand. This implies that
    • it should be easy to link items to one another
    • User should not have to switch views constantly just to see different types of items
    • An item should be able to belong to multiple groups, categories or, more traditionally, "folders"
    • it should be relatively seamless to move or copy an item from one grouping to another

Below we describe our current thinking on Generic Info Mgmt issues:

• Organizing by workflow: We believe the best description of task-centric workflow is found in David Allen's book " Getting Things Done". A one-page summary diagram can be found at his website. I briefly describe the five stages below of workflow and how they apply to Chandler below:
  • Brief synopsis: We (1) collect things that command our attention; (2) process what they mean and what to do about them; and (3) organize the results, which we (4) review as options for what we choose to (5) do
  • [OI] Collect In this mode, users collect everything new in their head into the Chandler "inbox". Emails are automatically collected by Chandler. However, users should be able to store notes, tasks and events into Chandler in a seamless ad-hoc fashion (with little cognitive overhead). How users enter this information has been discussed a little but is still an open issue. JottingNewItemsWorkflow describes possible solutions.
  • Process In this stage, you want to go through all your unfiled to dos, unread emails and upcoming events as quickly as possible to stay on top of things. So, Mimi has proposed that Chandler provides a turbo-charged inbox or Today View to facilitate this. Many details to be worked out. See GrandUnifiedTheoryOfBasicCapplets for more details. (see end of doc for link to open issues)
    • [OI] Does the Today View supplant the generic viewer?
  • Organize In this stage, you want to categorize your items and task status into meaningful groupings. Following are types of groupings we are focusing on:
    • By Status. What state is a task at? What is the next action? Examples of workflow groupings are:
      • Reply needed list
      • Next Action list
      • Waiting for or Pending list
      • Reference list
      • Someday/Maybe list
      • Tickler list
    • By Project. A project is just an activity that requires multiple steps or tasks. It is up to the user to decide the scope or granularity of a project. [OI] An open issue is whether projects have subprojects.
    • By Spheres of life e.g. Work, Personal, Family, Hobbies. [OI] We have not decided if this grouping will be supported in a first-class way for Canoga
    • By an individual contact or group. We are using groups as a means to model "spheres of life"
    • By timespan or time frame, this grouping will probably be used in conjunction with above groupings
    • By item type i.e. Email, Calendar, Task, Notes and Contacts.
    • See VirtualFolders and for more details
    • Organizing by the above groupings is just the first and easiest step to fully customizing the right view for the user within the continuous landscape of information items. PushButtonLandscapeMetaphor^? describes how users can easily create more customized views for particularly suited for their current task at hand.
  • Review and Do. In reviewing, you want to get a big picture and how to prioritize your tasks. So, you would want to go through lists of items produced in the organizing phase above. In addition, in both reviewing and doing and really all other phases to a lesser degree, you need to get the right context in order to make the right decision or to perform the task. Here's is where an ad-hoc task-centric cluster of items becomes an important concept
    • We define a cluster to mean an ordered collection of items related to a specific context known only to the user (i.e. Chandler itself has no specific semantics of the context)
    • User should easily be able to create related items through clustering. For example, Mitch may receive an invitation to FOSDEM, the premiere European Open Source Conf. He should be able to quickly create a related task entitled "discuss if OSAF should attend FOSDEM at next Mgmt Meeting" in the same cluster as the email invitation.
    • See ItemClusters for more details
• LevelsOfUse Because Chandler is a new product and we envision it to appeal to a wide audience, we've also divided users into different levels depending on user sophistication and experience with Chandler. LevelsOfUse describes these levels and how the above workflows apply to each level of user.
• StampingWorkflow Besides creating related items in a cluster, users require an even lighter weight way of creating a task or an event from an existing item. This is analogous to flagging an email as a task or making a task a calendar event as well. See ItemStamping for more details
• Landscape, push buttons and memorized views as user model metaphors. This needs to be written up and developed further. See Big ideas#landscape^? for more details (see end of doc for link to open issues)

User, Contacts and Groups

• There are some key issues around users and groups as described in SchemaNov2003Questions.
• Primarily the key issues are whether to unify the variants in our conceptual understanding of "groups" and "users".
• Our tentative decision is to see if we can unify each of these concepts and examine the corner cases to see if we can make this a final decision.
• In addition, Brian is in the process of writing up the set of decisions and remaining open issues around these topics

*See SumDoc20031105 for Mimi's summary of the Visual Design space.

NextStepsAsOf111403

-- ChaoLam - 15 Nov 2003