Design Issues Meeting 17 Nov 2003

Note: I (KDS) am not convinced that I understood everything for this meeting. I want to get the participants to review it before 'announcing' it. It has not yet been 'blessed'.

Attending: MitchKapor, MimiYin, BrianDouglasSkinner, DuckySherwood

Editorial Note: while this document reflects the best understanding of the participants as of 17 November 2003 of Canoga, our beliefs and understanding will undoubtedly change in the future.

We had all read Chao's DesignSummary, and were all pretty pleased with it. We will give Chao individual feedback when he gets back.

We moved on to discussing NextStepsAsOf20031114. (Editorial note: if you are trying to follow along, we skipped around a bit.)

Ubiquitous Item Entry Box

One question was whether the ubiquitous "IM-like" text entry box would be a Canoga feature. (See JottingNewItemsWorkflow#ubiquitousTextBox.) Mimi reported that she thought Chao thought they would not be in Canoga, and Ducky speculated that it was because "recognizers were out".

Mitch clarified that he believed that we do in fact need to defer generalized recognizers -- that a massive architecture for generalizing recognizers and allowing plug-in recognizers was not feasible for Canoga. However, he was quite open to special-cases of "fixed-purpose recognizers" for things like URLs, "next Thursday", names of contacts, etc. The ubiquitous item entry box then gives a way of entering new items that is much simpler than any kind of in-place editing.

(Side note: Mitch reports that Katie thinks that we should shoot for putting in some kind of very simple CPIA view into 0.3, and the ubiquitous item entry box is one possibility -- but we don't need to decide this right now. @@@ Mitch--is this a correct interpretation?)

Clusters

We discussed the DickGoesToREI scenario at length. (Editorial note: if you are reading along, you should probably detour to read that scenario. I promise it's quick.) Mitch suspects that Dick is on the "power user" end of the spectrum of users, and suspects we need a very lightweight way to support this use case. He suggested perhaps having a "scratchpad" where you could drag items to make ad hoc groupings of items. Even if those items then lost all connection to their original elements (i.e. you couldn't edit a task in the scratchpad and have the change propagate back to the original Task Item), even then, a scratchpad might be useful.

We then had quite a bit of discussion about what Dick would see when the "buy Ski mask" Task was the focus. We decided that when the "buy Ski mask" Task is the focus, Dick will see the "go to REI" cluster and the "break into Watergate" cluster as two separate clusters.

Mitch made the observation that attributes are a kind top-down way of organizing, while clusters are more bottom-up. Having clusters in Chandler feels right to him because sometimes people organize top-down, sometimes bottom-up. Mitch noted that lightweight clusters would solve a problem he saw in Agenda -- people could only group items by adding an attribute -- which somehow just felt wrong when it only applied to e.g. eleven out of 4000 items.

Mimi noted that this simplifies threads -- the user can choose between linking to a thread and linking to an item in a thread.

Mimi said that if item A is the focus, and item A is in three clusters, the user should be able to see all of the three clusters collapsed. The user should then be able to expand any of three clusters without changing focus (i.e., the user shouldn't have to switch views to see the expanded groups). However, if the user wants to see OTHER tasks related to a task in the cluster, they would need to switch focus to that item. (@@@ Mimi -- switch focus or switch View?)

We talked about what structure clusters should have. It was clear that we wanted either ordered lists or trees. In order to do email threading, we probably need to have a tree structure (although Mimi voted for displaying even email threads as simple ordered lists). In general, however, representing hierarchical lists visually is difficult. One compromise would be to give clusters a hierarchical representation internally (which we would use for email threading) but only give the user affordances for making ordered lists. Mitch felt it makes sense for now to represent clusters in the data model as hierarchies but to defer a decision about how we'll represent them in the UI. (@@@ Mitch -- correct interpretation?)

Item Stamping

(Editorial note: see ItemStamping for background. Some discussion related to when should there be one item or two omitted on the grounds that it very similar to material covered in other meetings.)

Mimi presented a pair of questions to clarify when something should be one item and when there should be two linked items.

1. Are there any situations where you're looking at the detail view of one item and don't want to see the other items?
2. If you link one, do you ever want to not link the other?

There is consensus that Task and Calendar ought to be one item, as you never answer "yes" to either of the above questions when talking about a meeting with Jack (T) at 4 pm (C). The TaskCalendarEvent should have the union of the Task attributes and Calendar attributes.

For the case where an email message has a Task in it, if Mitch stamps the item with a Task, he wants a separate Task to be created which pulls its description from the subject line and linked to the email message. Mimi doesn't want the users to be forced to edit the task, as some users won't ever go to their Tasks list.

Ducky asked what the procedure was if three tasks were enumerated in the message? Would the user stamp the message three times? Mitch didn't think so. Mitch felt that the Task checkbox just indicated, "you need to do something with this." For anything more elaborate, it was okay if the user had to do a slightly more heavyweight Task creation or editing manipulation.

Mimi mentioned that Email messages and Tasks must be two items because the user can edit the Task but not the email message. (Editorial note to people who are upset at the thought of not being able to edit messages: you will probably be able to annotate messages, but not to destroy the integrity of the original message.)

Someone floated the question of whether for Canoga, we could do something like iCal where Tasks have to be events (i.e. have times associated with them). A resounding "no!" was heard. The consensus was that many tasks don't naturally have a do-on date, so wouldn't show up well in a calendar.

Terminology

There was some discussion of terminology related to Projects.GlossaryOfKeyEndUserTerminology#Terminology_Questions. (Editor's note: These are all "consensus" items, but don't fit nicely in the short bulleted list format of the Consensus section.)

Favored term	Deprecated term
CPIA View	CPIA Document
Independent Grouping	Orthogonal Bucket
Content Item	Information Item
View template	Template
Contacts	Address Book

There was also discussion about the meaning of some terms.

• A cluster is a structured collection.
• A context is the visual presentation of a capplet. Every capplet has one context, every context belongs to one capplet.
• A context is a specialized type of CPIA View, but not all CPIA Views are contexts.
• A parcel is a unit of code. All capplets are parcels, but not all parcels are capplets. Parcels are roughly equivalent to "plug-ins" of code. Parcels do not need to have their own UI; for example, there might be a spellchecking parcel.

We also discussed using "database" instead of "repository", on the grounds that people knew what a database was. Mitch was nervous about that -- he worried that people would think "relational database", and for the next 10 years, we'd have to cope with people having faulty mental models because of that.

Mitch would like "repository" to mean data, "repository code" to mean the code to get at the data. We need a bit more work on nomenclature for stuff.

Mitch voted for axing "repository partition" in Projects.GlossaryOfKeyEndUserTerminology#Terminology_Questions. He feels that repository sharing will on the granularity of a Calendar or an Address book. (@@@ Mitch, Brian -- just how deprecated is the term "Address Book"?) If users want to share an individual item, they will need to wrap some view stuff around it.

Parenthetically, Mimi felt that there will be views of information that show one item type only.

For the names of capplets, Mitch prefers

• Mail
• Calendar
• Tasks
• Contacts
• Notes

In particular, Chandler will not use the term "Address Book."

Summary

Consensus

• Canoga will have a ubiquitous text entry box for creating Content Items.
• A Content Item can be in multiple clusters.
• If an item is in two clusters, and you another item onto the first (to make a link), it goes into a new cluster. If the user wants to add it to an existing cluster, the user needs to do something else (TBD) to add it to a cluster.
• Clusters can be named.
• If item X is in two clusters, when item X is the focus, both clusters will be visible. Both clusters can be expanded, but if the user wants to see items related to other items in the cluster, the user will need to switch views.
• The internal representation of cluster is as a hierarchical tree. (@@@ Was this decided for sure?)
• We will implement email threads with Chandler clusters. (@@@ Was this decided?)
• Task (T) and Calendar Event (C) are one Kind, a TaskCalendarEvent (TC).
• If X and Y are linked together, and the user wants to link item Z to both X and Y, the user needs to select both X and Y, then create the link. Otherwise, Z will only link to whichever of X and Y was selected.
• Stamping an item is a single operation. For example, stamping an email item seventy billion times with the Task stamp still only gets you one linked Task and one checkbox.
• Consensus was reached on a number of terminology issues (see above).

Open Issues

• How much recognizing will the ubiquitous item entry box be capable of?
• For any of predefined Content Item Kinds, the user can add new attribute, which has "hideous" implications for sharing.
• What is the word for a generic set of all of a set of related items of a class (e.g. a Calendar (like "the San Jose Sharks hockey game Calendar), or a Task list)? (@@@ Mitch -- do I understand these to be what you called "frobbs"?)
• If the user deletes an email message stamped as a task, or marks it "done", does it show up in their task list?

-- DuckySherwood - 17 Nov 2003