Design Issues Meeting 11 November 2003

Attending: MitchKapor, MimiYin, ChaoLam, BrianDouglasSkinner, DuckySherwood

This meeting consisted of going methodically through issues that Brian raised in his Schema questions doc. As such, it is almost all consensus items or open issues, which are collected below.

Rich interconnections

It would be highly useful to be able to click on a name in a record (e.g. Janice Huber in the Spouse field) and go to Janice's contact record. However, if Janice doesn't have a record, it would be nice to just have the plain (not hyperlinked) text "Janice Huber". It would thus be highly useful to be able to have attributes with values of either a String or an Item (e.g. Contact) or both. Of course, it would also be nice to have a mixed collection, where Janice Huber and "Joyce Huber" could coexist.

One way to do this would be sort of like how the wiki handles links to wiki pages that don't exist yet; instead of storing a String for people who don't yet have Contact records, store a link to a "create me" page.

There was a discussion of using Items called "Locations" in Contact records as a way to avoid retyping information for multiple people at that address. Locations might also be useful in Tasks for filtering what tasks you can work on where you are.

Consensus

• A center of design for Canoga 1 is to exploit rich interconnection in a modest way. We want to do a few really cool things and defer a bunch of cool things.
• From a user standpoint, we want to be able to query to let people see all email messages from a given sender, but that a search is likely to be more lightweight than having the Contact Item keep a list of related messages.
• It might also be useful to have an easy way to jump from viewing a Contact to viewing any of the Groups that the Contact belongs to.
• In Canoga 1, we don't need to minimize retyping in Contacts for groups of people who share some information (like street address).
• Locations do not need to be in Canoga 1.
• A Contact can be related to other Contacts, but only as a whole. In other words, you can't link to "Jim Fredrix' work persona" or "Jim Fredrix' home persona", just to "Jim Fredrix".
• We want to support linking people to organizations.
• Canoga won't automatically keep around out-of-date information (e.g. email addresses for the purpose of connecting a Contact with email messages that they'd sent with their old address). If the user wants to keep it around, they will need to do the work to keep it around.
• Canoga won't have versioning of information.
• Canoga won't have an easy mechanism for marking Contact information as "out-of-date" except by deleting it.
• Canoga will not mine bounce messages for information about the (in)validity of an email address (though we won't be surprised if volunteers create all kinds of tools for mining email messages for data).
• Roles in Contacts (e.g. "Marketing Manager at Cisco") are deferred until past Canoga 1.
• Calendar Events will have recurring event groupings and Calendar groupings (as in "San Jose Opera's Calendar"), but not related events or sub-events.
• We want to support several types of Strings, including those with rich text and "live" URLs.
• Canoga should allow incompletely specified timedates, including such things as "October 14th, 2003" or "October 2003". This will provide a mechanism for all-day events, tasks that need to happen sometime in July, etc.
• Canoga should support durations (independent of start and end time). For example, you might have a duration of 2 hours on a Task well before you decide when to start the task.
• We need to support both "delete from repository" and "delete from collection".
• Chandler won't garbage collect items. If there is an item that no longer has links to it, it should be visible in a "orphan/not yet filed items" view.
• A "repository" is the data that one user can see (as opposed to the set of all repositories managed on one machine).

Open Issues

• Does a Contact store information about {past IM messages from this person, Items they've published, Items I've published that they've subscribed to, permissions I've given them or they've given me, Items of mine that they've browsed} or vice-versa?
• Does a Contact store information about RSS feeds that they're the author of, or weblog posts, or web pages?
• Should the Email capplet have information about whitelists and blacklists? If so, will that be stored in Contacts or not?
• Should the data model support Strings with Items in them?
• Should the data model have a "Timespan" type that includes information about the start time and the duration?
• What is the name for a set of repositories all on one machine? "The repository space"?

Action Items

• Brian to explore multi-value collections, see how hard it is, and get back to us.
• Mimi to determine where links to people in Contacts go to (a Contact detail View? the Repository Viewer?)
• Mimi to explore possibilities for cool features around sharing email mailing lists.
• Brian and Chao to discuss interoperability requirements.
• In next meeting, Mimi to give recommendations for navigation of thrasks.
• Chao to prep next week's meetings' agenda items before he leaves.
• Ducky to write up and distribute meeting minutes.

Potential cool features

• In email, sort-by-person as opposed to sort-by-name or sort-by-address.
• A UI affordance for scheduling a task somewhere in a block of time. See ShowingTaskTimesInFreeBlocks.
• Sharable address books.
• Sharable email mailing lists administration (so that it's easier for many people to administer a list).
• An "Undo" command when synching.

-- DuckySherwood - 12 Nov 2003