Design Issue Meeting 6 November 2003

Attending: MitchKapor, AndyHertzfeld, MimiYin, ChaoLam, BrianDouglasSkinner, DuckySherwood. A candidate for manager sat in for most of the meeting.

Agenda:

• Clarification of target user
• Discussion of most common user scenarios
• Discussion of "virtual folder problem"
• Scope and approach of Notes

Clarification of target user

Lots of consensus here:

• Our target user is a non-technical power-user. Someone who is in need of a powerful information management application, but is neither a programmer nor "like" a programmer in the way she thinks.
• Our user is not necessarily good at organizing things and has not found smart ways to bend existing PIMs to better serve her information management needs.
• Chandler's default configuration should help this target user manage her information significantly better than what she can do today with her PIM without much customization on her part.
• We are not building Chandler for a occasional user who is technically naive.
• Because non-technical people are not always good at formal procedural logic, Chandler can't require lots of customization.

Other decisions about the focus of Chandler:

• In the tension between platform and application, Chandler must be a great application first. We want to build in specific features that are useful to a power user, not to provide a generic set of features and wait and see how people wire them up.
• Email/Tasks/Calendar are the critical bits. Contacts are important but Contacts have a different lifecycle: E/T/C items are born, live, and die pretty quickly. An important goal with E/T/C items is to process them and move on. Contacts are more like long-lived reference material, so its interaction affordances are different.
• While documents (e.g. word processing documents, not CPIA documents) are important to Chandler, they are important in the service of processing E/T/C items.
• A good document management structure is outside the scope of Chandler. (KDS: unsure of consensus on this.)

Discussion of most common user scenarios

Use case: Jane is reading email and says, "Oh, this message describes a task." We need a single action for "create a new linked action". There are many ways to do this, but one example would be just to "stamp" the email with a Task stamp (sort of like setting a flag).

There's also a use case where Jane reads the message realizes that she needs to create a task, but that the text in the email message isn't appropriate to use as the text in the Task. In that case, there needs to be a very lightweight way for Jane to create a Task. Popping up a dialog was suggested, but something even lighterweight like entering text into an always-present text box (sort of like the text entry box in Chatzilla) might be even better.

Mitch feels that we should worry about this use case first, instead of the general issue of how to link items.

The detail view and summary view should both have ways of showing linked items. This brings up questions, but we're close enough that Mimi can look at it and make a proposal.

"Virtual folder" Problem

Items must be allowed to be in multiple folders, but how to you make that tractable?

A significant use case for multiple folders is setting the "workflow status" (yes, we need a better term) of a message. It would be useful for people to be able to very easily stamp messages with "ToDo" (e.g. to reply to, to act upon) or "Waiting" statuses, then be able to group messages by workflow status, e.g. "only email with status of 'ToDo'". Users could then save the query results as a CPIA doc, put it in the sidebar, and be able to see it again.

Mitch: The user could then drag a message to the 'ToDo' CPIA doc on the sidebar and that would change the message's attributes so that it satisfied the query.

Andy: Doing an inverse function of a query is difficult.

Mitch: We could special-case for simple status changes.

[OI] We need to figure out the difference between Task workflow statuses and Email statuses.

There was a brief discussion of the "playlists" metaphor. One nice aspect of playlists as a metaphor is that songs can be in more than one playlist. On the other hand, playlists have a temporal sequence, which some of our things (like Tasks and Notes) might not; it does not have a hierarchical structure, which many of our item collections might.

Categorizing messages by their workflow status is a first-class categorization type; Project is also important, but is orthogonal.

Visitor asked if the query itself was stored or if the results of the query were stored, and was told that however we do it, the query would always be up-to-date. (If querying is fast enough, you can always re-run the query.)

Visitor also mentioned that the X1 interface to MS Outlook is query-based.

There were some nervous noises in the room about integrating Chandler email with IMAP, but we mostly tabled that discussion for later. One question that is highly relevant to IMAP integration, however, is whether folders can live inside folders.

Notes

Chao had made up a list of questions that all got answered in the meeting; see NotesDetailedFeatureList^?. There were some open issues as well and some general consensus items from the meeting that have been added to NotesDetailedFeatureList^?.

There was a discussion of using a Note field in Contacts. Ducky interpreted something Mimi said as saying that if we did a better job with Contacts, that you wouldn't need as many Notes. Example: one Note with 800 airline phone numbers could be recognized and parsed out into 800 separate Contacts.

Mitch disagreed -- that Contacts were best used for people and organizations that you have an ongoing relationship with. Cluttering up Contacts with info for people and orgs that you might conceivably have a relationship with someday was a bad idea. For one thing, it clutters up the search results.

Mimi mentioned that some people didn't like search, preferring contextual navigation. Mitch feels that's a fundamentally flawed strategy as the amount of information people have to deal with keeps getting bigger. While as a general strategy, we should allow people to do what they want to do, we are not optimizing Chandler to allow hierarchical categorization, but we are optimizing for good searching.

Mitch suggested that we wanted to have a single view that handles both tasks and notes, and that we should consider notes as often being little proto-tasks.

Summary

(KDS: Most of the meeting was consensus this time, so I won't call out the consensus items explicitly this time.)

Open issues

• [OI] We need to figure out the difference between Task workflow statuses and Email statuses.
• [OI] Can folders be inside folders?

Also see Trash.NotesDetailedFeatureList open issues^?.

Contributors

• DuckySherwood - 07 Nov 2003
• BrianDouglasSkinner - 08 Nov 2003