Design Issues Meeting 10 November 2003

Attending: MitchKapor, MimiYin, ChaoLam, BrianDouglasSkinner, DuckySherwood

(KDS: There was a lot of consenus in this meeting. Because I put all the consensus items together in the Consensus section at the bottom of this document, the "meat" of the meeting seems smaller than it actually was.)

PIM Schema

We started with a discussion of the PIM schema, based on Brian's SchemaNov2003Questions.

Mitch expressed a little concern about too many degrees of freedom. In particular, suppose there is an official "OSAF Calendar" that has our IRC schedule, public presentations, etc. Now suppose that someone working on Chandler creates an "OSAF" Project to put tasks. At some point, our user also decides to put some meetings with the UI team into the OSAF Project. There are huge opportunities for the user to get confused between the "OSAF Calendar" and Calendar Events that are tagged with the "OSAF" project.

There was some discussion of Calendars and whether each Calendar was a Project or not. They might be related; for example, perhaps the act of subscribing to the Freeble Calendar tags all of those events with the "Freeble" project. That could perhaps be done by a "micro agent" that acts sort of like a "Smart Playlist" in iTunes.

Groups

There are a bunch of different types of groups in Chandler, and some unification would be nice. The groups include:

• People (who don't have Contact information)
• Contacts (who have address, email, whatnot information)
• Users (who also have access control information related to Chandler sharing)
• email addresses, jabber accounts (individual items, separate and distinct from Contacts)
• "Me" -- which has information about the user

Mitch feels strongly that if there is more than one type of record for humans, users will get completely confused. Also, if the person doesn't have any information in Chandler, they don't exist.

You might want to share information with someone who you don't have Contact information for. You can have IM buddies that you don't have Contact information for, or Contacts that you don't have on your buddy list.

A related issue is that of picking from several different addresses (email addresses, IM addresses) that a Contact could have. There was some discussion of personas -- subgroups of Contacts. This made Mitch nervous -- he was worried about complexity.

Personas are also potentially useful for setting what role you are in, e.g. for accounts. You might want to select which persona you're sending a message from. Mitch said that he thought it was better to select that on a per-ID basis instead of a per-persona basis.

Organizations: how do we handle organizations? "Home phone number" doesn't make sense for a company. Mitch mentioned that the Apple way of doing it (a checkbox for "this is a company") works well.

Mitch feels that as a working hypothosis, anything that you can do for an individual, you should be able to do for a group.

There was some discussion of SBook5-type data entry. Mimi asked when something stopped being a Note and when it started being a Contact. Brian asked if we were going to support SBook5-ish records -- if so, that would have have huge implications for the data model.

Ducky asked if maybe we wanted to support very lightweight recognizers, where the user had to explicitly highlight some text and push a "recognize me" button to get a draggable icon that could then be dragged to the appropriate place.

Mitch feels that we can ship Canoga 1 without any sort of recognizers, and that the community might pick up recognizers as a cool project to do.

There was more, but we decided to table it so that we could move on to Tasks.

Tasks

The schema for Task will inherit some things from Information Item, including Project. Other potentially useful fields include status (done/not done/pending), requestor, requestee, dependencies (forwards and backwards), "do on" timedate, sub-tasks, urgency, and importance.

Note -- after the formal meeting, Mimi, Brian, and Ducky talked briefly among ourselves. Ducky asked if Projects could have sub-projects, if Sphere of Life would just be the top nodes of the Project hierarchy. Mimi mentioned that she was very nervous about encouraging users to create complex hierarchies, as users traditionally haven't done a very good job of managing hierarchy (perhaps because the tools for managing hierarchy have not been very good).

Consensus Items

• Any query can be basis of a virtual folder.
• While "Project" is a specific, well-defined term in Chandler-land, "category" is a fuzzy English-language word.
• Projects can have sub-projects.
• Hierarchical groups would be nice but are not necessary to ship Canoga 1.0.
• "Me" is a distinguished Contact.
• Account information (e.g. email server) for "Me" lives separately and should not encumber all the other Contact records.
• One useful reason for a "Me" account is to make it easier to share "my" information easily.
• When you initiate communication with someone (IM or email), you select the contact method by ID, not by name.
• Generalized recognizers are not going to be in Canoga 1, though specific feature-by-feature recognizers (like URLs) might.
• Canoga task management should be simple and will not deal with interpersonal task management.
• The schema for Tasks should be very simple.

Open Issues

• [OI] What additional default optional attributes do we want to give Information Items?
• [OI] Do we want to add "Sphere of Life" to the default schema?
• [OI] What does the "workflow status" of an email message have in common with the "workflow status" of a Task?
• [OI] How do Calendars and Projects interact?
• [OI] Does information from "Me" flow through to account information (or vice versa)?
• [OI] Where do access control permissions live -- in Contacts or a separate Item?
• [OI] What Contact information should the Email Capplet capture?
• [OI] What information should the Email Capplet gather from Contacts (e.g. autocomplete from history list)?
• [OI] Is the "requestor" in a Task the person who makes the request or the person to whom the task is "owed"? If Chao asks Ducky to write a report for Mitch, is Chao the requestor or is Mitch?
• [OI] Can a Task depend upon an event?
• [OI] Do you need both sub-tasks and dependencies in the Task schema?
• [OI] Do you need both sub-tasks and Projects in the Task schema?
• [OI] Can you convert Tasks to a Project?

Action Items

• Brian is to go as far as he can with single, unified group strategy, see where it breaks down, and return with issues if it does. This includes merging Users and Contacts and allowing users to do anything with a group that they could do with an individual.
• Chao to send out an agenda for tomorrow's meeting.
• Ducky to write up meeting notes.

-- DuckySherwood - 11 Nov 2003